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Abstract: A new formal model is presented, for studying concurrency and resiliency propertics for nested 


transactions. ‘he model is used to state and prove correctness of a well-known locking algorithm. 


1. Introduction 

‘This paper develops the foundation for a general theory of nested transactions. We present a simple formal 
model for studying concurrency and resiliency in a nested environment. ‘This model has distinct advantages 
over the many alternatives, the greatest of which is the unification of a subject replete with formalisms, 
correctness conditions and proof techniques. The authors are presently engaged in an ambitious project to 
recast the substantial amount of work in nested transactions within this single intuitive framework. ‘These 
pages contain the preliminary results of that project - a description of the modcl, and its use in stating and 


proving correctness conditions for two variations of a well-known algorithm. 


‘The model is based on //O automata, a simple formalization of communicating automata. It is not complex 
- it is easily presented in a few pages, and casy to understand, given a minimal background in automata 
theary. Each nested transaction and data object is modclicd by a separate 1/O automaton. ‘These automata, 
the system primitives, issue requests to and receive replies from some scheduler, which is simply another 1/O 
automaton. Simple syntactic constraints on the interactions of these automata censure, for example, that no 
transaction requests the creation of the same child more than once. One scheduler, in this case the "serial 
scheduler", interacts with the transactions and objects in a particularly constrained way. ‘The “serial 
schedules" of the primitives and the scrial scheduler arc the basis of our correctness conditions. Spccifically, 
alternative schedulers are required to ensure that nested transaction automata individually have local 
schedules which they could have in a scrial schedule. In essence, each scheduler must “fool” the transactions 


into believing that the system is exccuting in conjunction with the scrial scheduler. 


In the past ten years, an important and substantial body of work has appeared on the design and analysis of 


algorithms for implementing concurrency control and resiliency in database transaction systems 


[EGI-T.RES,BG,KS,Gr,La8, ctc.]. Among this has been a number of results dealing with nested transactions 
[R.Mo.L iS. LIWESW.AM, BBGLS. BBG, etc.]. ‘The present work docs not replace these other contributions, 
but augments them by providing a unifying and mathematically tractable framework for posing and exploring 
a variety of questions. ‘This previous work uses behavioral specifications of nested transactions, focusing on 
what nested transactions do, rather than what they are. By answering the question "What is a nested 


transaction?”, 1/O automata provide a powerful tool for understanding and reasoning about them. 


Some unification is vitally important to further development in this ficld. ‘The plethora and complexity of 
existing formalizations is a challenge to the most scasoned researcher. More critically, it belies the argument 
that nested transactions provide a clean and intuitive tool for organizing distributed databases and more 
general distributed applications. It is particularly important to provide an intuitive and precise description of 
nested transactions themselves, as in typical systems, these are the components which the application 


programmer must implement! 


‘The remainder of this paper is organized as follows. ‘The 1/O automaton model is described in Section 2. 
‘The rest of the paper contains an extended example, which establishes correctness properties for two related 


lock-based concurrent schedulers. 


Section 3 contains simple definitions for naming nested transactions and objects, and for specifying the 
operations (interactions) of these componcnts. Simple syntactic restrictions on the orders of these operations 
are presented, and then a particular system of 1/O automata is presented, describing the interactions of nested 
transactions and objects with a serial scheduler. ‘The interface between the scrial scheduler and the 
transactions provides a basis for the specification of correctness conditions for alternative schedulers. These 
schedulers would presumably be morc efficient than the scrial scheduler. ‘he strongest correctness condition, 
"serial correctness," requircs that a// non-access transactions sce scrial behavior at thcir interface with the 
system. The second condition, "correctness for Ty." only requires that this scrial interface be maintained at 
the interface of the system and the external world. These interfaces also provide simple descriptions of the 
environment in which nested transactions can be assumed to execute. A particular contribution is the clear 
and concise semantics of ABORT operations which arises naturally from this formalization. The section 


closes with a collection of lemmas describing uscful propertics of scrial systems. 


Next, a lock-based concurrent system is presented. Scction 4 contains a description of a spccial type of 
object, called a "resilient object", which is used in the concurrent system. Scction 5 describes the remainder 
of the concurrent system, the "concurrent scheduler." This concurrent scheduler includes “lock manager" 


modules for all the objects; lock managers coordinate concurrent accesses. 


Section 6 defines a system which is closely related to the concurrent system, the "weak concurrent system." 
‘This system preserves serial correctness for those transactions whose ancestors do not abort (ic. those that are 
not “orphans"). Since the root of the transaction uree, Ty has no ancestor, weak concurrent systems are 
correct for ‘Ty. Section 7 contains complete proofs of correctness of the concurrent and weak concurrent 
sytems: concurrent systems are serially correct, and weak concurrent systems are correct for Vo: ‘The stronger 


condition is obtained for concurrent systems as a corollary to a result about weak concurrent systems. 


It is interesting that the concurrent system algorithms are described in complete detail (essentially, in 
“pscudocode”), yet significant formal claims about their behavior can be stated clearly and casily. Although 
the full presentation involves a large number of lemmas, the idcas described by the lemmas are quite simple 
and intuitive. We think it is remarkable that these interesting propertics of concurrent systems can be proved 
with complete rigor, in full detail, in so short a development. Despite the detailed level of presentation, the 


underlying model is gencral enough that the results apply to a wide range of implementations. 


The style of the correctness proof is also noteworthy. [tis a constructive proof, in that for cach step of the 
weak concurrent system and cach non-orphan transaction, an execution of the scrial system is explicitly 
constructed. ‘The transaction’s local “view” in the constructed exccution is identical to that in the original 
weak concurrent execution, establishing the correctness of the weak concurrent system. One may think of the 
weak concurrent system as maintaining consistent, parallel “world views” within which concurrent siblings 
execute. As siblings return to their parent, these parallel worlds are “merged™ to form a single consistent 
view. The locking policy prevents collisions between different views at the shared data. ‘This intuition is 
strongly supported and clarified by the correctness proof, which constructs the parallel views as different 
scrial schedules consistent with cach sibling’s local history. lemmas illustrate how these serial schedules can 


be merged as siblings return or abort to their parent. 


Section 8 contains a discussion of the relationship of this work to previous results, and Scction 9 contains an 


indication of the work that lics ahead. 


2. Basic Model 

In this section, we present the basic [/O automaton model, which is used to describe all componcnts of our 
systems. This model consists of rather standard, possibly infinite-state, nondeterministic automata that have 
operation names associated with their state transitions. Communication among automata is described by 
identifying their operations. This model is very similar to modcls used by Milner, Hoare [Mi,Ho] and others. 
There are a few differences: first, we find it important to classify opcrations of any automaton or system of 
automata as cither "input" or “output” operations, of that automaton or system, and we treat these two cases 


differently. Also, we allow identification of arbitrary numbers of operations from different automata, rather 


than just pairwisc identification as considered in [Mi]. 


This paper is not intended to develop the basic model. For the general theory of 1/O automata, including a 
unified treatment of finite and infinite behavior, we refer the reader to [LT]. In the present treatment of 
concurrent transaction systems, we only prove propertics of finite behavior, so we only require a simple 


spccial case of the general model. 


2.1. 1/O Automata 

All components in our systems, transactions, objects and schedulers, will be modelled by //O automata. An 
1/O automaton A has components statesxA), start(A), oul(A), in(A), and steps(A). Here, sfates(A) is a sect of 
states, of which a subset stari(A) is designated as the sct of start states. Vhe next two components are disjoint 
sets: out(A) is the set of oulput operations, and in(A) is the set of input operations. ‘Vhe union of these two 
sets is the set of operations of the automaton. Finally, steps(A) is the transition relation of A, which is a set of 
triples of the form (s’,a,s), where s' and s arc states, and @ is an opcration. ‘This triple means that in state s’, 
the automaton can atomically do operation @ and change to state s. An clement of the transition relation is 


called a step of A. 


The output operations are intended to model the actions that are triggered by the automaton itself, while 
the input operations model the actions that are triggered by the environment of the automaton. Our 
partitioning of operations into input and output indicates that cach operation is only triggered in onc place. 


We require the following condition. 


Input Condition: For cach input operation w and cach state s’, there exist a state s and a step (s’,9,S). 


‘This condition says that an [/O automaton must be prepared to receive any input operation at any time. 
‘This condition makes intuitive sense if we think of the input opcrations as being triggered externally. (In this 
paper, this condition serves mainly as a technical convenience, but in [IT], where infinite behavior is 


considered, it is critical.) 


An execution of A is an alternating sequence $9.7 ;, S),77>.... of states and operations of A; the sequence may 
be infinite, but if it is finite, it ends with a state. Furthermore, Sy is in start(.A), and cach triple (s’,7.s) which 
occurs as a consccutive subsequence is a step of A. From any execution, we can extract the schedule, which is 
the subsequence of the execution consisting of opcrations only. Because transitions to different states may 


have the same opcration, different executions may have the same schedule. 
Lemma 1: If @ is a schedule of {/O automaton <A, then every prefix of a is a schedule of A. 


if S is any set of schedules (or property of schedules), then A is said to preserve S provided that the 
following holds. [fa = a’a is any schedule of A, where 7 is an output operation, and a is in S, then @ is in 


S. ‘That is, the automaton is not the first-to violate the property described by S. 


2.2. Composition of Automata 
We describe systems us consisting of interacting components, cach of which is an 1/O automaton. It is 
convenient and natural to view systems as 1/O automata, also. ‘hus, we define a composition operation for 


{/O automata, to yield a new I/O automaton. 


A set of [/O automata may be composed to create a system Ff, if all of the output operations are disjoint. 
(Thus, every output operation in f will be triggered by exactly one component.) ‘The system F is itself an 1/O 
automaton. A state of the composed automaton is a tupte of states, one for cach component, and the start 
Statcs are tuples consisting of start states of the components. ‘The sect of operations of F, ops(f), is exactly the 
union of the sets of operations of the component automata. ‘The set of output operations of £, out(f), is 
likewise the union of the scts of output operations of the component automata. Finally, the sct of input 
operations of ¥, in(¥), is ops{F) - out(F), the sct of operations of F that are not output operations of Ff. ‘The 
output operations of a system are intended to be exactly those that are triggered by components of the system, 


while the input operations of a system are those that are triggered by the system’s cnvironment. 


The triple (s',2,s) is in the transition relation of £ if and only if for cach component automaton A, one of the 
following two conditions holds. Either a is an operation of A, and the projection of the step onto A is a step 
of A, or else w is not an operation of A, and the states corresponding to .A in the two tuples s’ and s are 
identical. ‘Thus, cach operation of the composed automaton is an operation of a subsct of the component 
automata. During an operation w of ¥, cach of the components which has operation @ carrics out the 
operation, while the remainder stay in the same state. Again, the opcration q is an output operation of the 
composition if it is the output opcration of a component - otherwise, 7 is an input operation of the 


composition.! 


Lemma 2: The composition of [/O automata is an I/O automaton. 


The next lemma allows us to compose automata in any order. 
Lemma 3: Up to isomorphism, composition of I/O automata is associative and commutative. 


'Note that our model has chosen a particular convention for identifying operations of different componcnts in a system: we simply 
identify those with the same name. ‘this convention is simple, and sufficient for what we do in this paper. Ilowever, when this work is 
extended lo more complicated systems, il may be cxpedicnt to generalize the convention for identifying operations, to permit reuse of the 
same operation name internally to different components. ‘This will require introducing a renaming operator for operations, or clse 
defining composition with respect to a designated equivalence relation on operations. We leave this for later work. 


An execution of a system is defined to be an execution of the automaton composed of the individual 
automata of the system. If @ is a schedule of a system with component A, then we denote by aA the 


subsequence of @ containing all the operations of A. Clearly, a[A is a schedule of A. 


Lemma 4: [ct a@° be a schedule of a system ¥, and Iet a = aa, where a is an output operation 
of component A. If alA is a schedule of A, then @ is a schedule of ¥. 


Proof: Since aA is a schedule of A, there is an execution B of A with schedule a|A. Let B* be 
the execution of A consisting of all but the last step of B. Similarly, since a’ is a schedule of F, 
there is an exceution y of Ff with schedule a. It is possible that A has an execution in y which is 
different from £°, since different executions may have the same schedule. But it is easy to show, 
by induction on the length of y, that there is another execution y’ of Ff in which component A has 
execution B, and which is otherwise identical to y. ‘The schedule of y' is a’. Since w is not an 
output operation of any other component, 7 is defincd from the state reached at the end of y’, so. 
that a = a’ is aschedulc of ¥. & 


3. Serial Systems 

In this paper, we define three kinds of systems: "scrial systems" and two types of "concurrent systems”. 
Scrial systems describe scrial execution of transactions. Scrial systems are defined for the purpose of 
providing a correctness condition for other systems: that the schedules of the other systems should “look 
like” schedules of the scrial system to the transactions. As with scrial schedules of single-level transaction 
systems, our scrial schedules are too inefficient to usc in practice. ‘Thus, we define systems which allow 
concurrency, and which permit the abort of transactions after they have performed some work. We then 


prove that the schedules permitted by concurrent systems arc correct. 


In this section, we define "scrial systems". Scrial systems consist of "transactions" and “basic objects” 
communicating with a "serial scheduler". ‘Transactions and basic objects describe user programs and data, 
respectively. ‘The serial scheduler controls communication between the other components, and thereby 
defines the allowable orders in which the transactions may take steps. All three types of system components 


are modelled as 1/O automata. 


We begin by defining a structure which describes the nesting of transactions. Namcly, a system type is a 
four-tuple (J:parent,O,V), where J, the set of transaction names, is organized into a tree by the mapping 
parent:7 — J, with 1, as the root. In referring to this tree, we usc traditional terminology, such as child, leaf, 
Icast common ancestor (Ica), ancestor and descendant. (A transaction is its own ancestor and descendant.) 
The leaves of this tree are called accesses. The set O denotes the sct of objects; formally, O is a partition of the 
set of accesses, where cach element of the partition contains the accesses to a particular object. The sct V is a 


sct of values, to be used as return valucs of transactions. 


The tree structure can be thought of as a predefined naming scheme for all possible transactions that might 


ever be invoked. In any particular execution, however, only some of these transactions will actually take 
steps. We imagine that the tree structure is known in advance by all components of a system, ‘The tree will, in 


gencral, be an infinite structure. 


The classical transactions of concurrency control theory (without nesting) appear in our model as the 
children of a “mythical” transaction, Tis the root of the transaction tree. (In work on nested transactions, such 
as ARGUS [L iS .HJLSW, the children of I, are often called “top-level” transactions.) It is very convenient 
to introduce the new root transaction to model the environment in which the rest of the transaction system 
runs. ‘Transaction ‘Ty has operations that describe the invocation and return of the classical transactions. It is 
natural to reason about Ny in much the same way as about all of the other transactions, although it is 
distinguished from the other transactions by having no parent transaction. Since committing and aborting are 
operations which take place at the parent of cach transaction (sce below), To can neither commit nor abort. 


‘Vhus, a commit or abort of a top-level transaction to ‘I, is an irreversible step. 


The internal nodes of the tree model transactions whose function is to create and manage subtransactions, 
but not to access data directly. The only transactions which actually access data are the leaves of the 
transaction tree, and thus they are distinguished as “acccsscs". ‘lhe partition O simply identifies those 


transactions which access the same object. 


A scrial system of a given system type is the composition of a sct of 1/O automata. ‘Vhis sct contains a 
transaction for each infernal (i.c. non-leaf, non-access) node of the transaction tree, a basic object for cach 
element of O and a scrial scheduler. ‘These automata are described below. (If X is a basic object associated 
with an clement & of the partition O, and ‘I’ is an access in G, we write T € accessesX) and say that "T is an 


access to X".) 


3.1. Transactions 

‘This paper differs from carlicr work such as [l-y,Go,Wel] in that we modci the transactions explicitly, as 
1/O automata. In modelling transactions, we consider it very important not to constrain them unnecessarily; 
thus, we do not want to require that they be expressible as programs in any particular high-level programming 
language. Modelling the transactions as [/O automata allows us to state exactly the properties that are 


needed, without introducing unnecessary restrictions or complicated semantics. 


A non-access transaction T is modelled as an I/O automaton, with the following operations. 


Input opcrations: 
CREATEC(T) 
COMMII(T’v), for I’ € children(T) and v € V 
ABORT(T), for I” € children(T) 


Output operations: 
REQUEST—CREATECT), for T € children(1) 
REQUEST—COMMPTICT\v), for v € V 


The CREATE input operation "wakes up" the transaction. The REQUEST — CREATE output operation is 
a request by ‘Tl to create a particular child transaction.21he COMMIT input Operation reports to T the 
successful completion of one of its children, and returns a value recording the results of that child's execution. 
The ABORT input operation reports to ‘T the unsuccessful completion of one of its children, without 
returning any other information, We call COMMIT(T’,v), for any v, and ABOR'T(!") return operations for 
transaction 1”. The REQUEST—COMMIT operation is an announcement by 'T that it has finished its work, 


and includes a value recording the results of that work. 


It is convenient to use two scparate operations, REQUEST—CREATE and CREATE, to describe what 
takes place when a subtransaction is activated. Vhe REQUEST—CREATE is an opcration of the 
transaction’s parent, while the actual CREA'TE takes place at the subtransaction itself. In actual systems such 
as ARGUS, this separation does occur, and the distinction will be important in our results and proofs. Similar 
remarks hold for the REQUEST—COMMIT and COMMIT operations.? We Icave the executions of 
particular transaction automata largely unspecified: the choice of which children to create, and what value to 
return, will depend on the particular implementation. For the purposes of the schedulers studied here, the 
transactions (and in large part, the objects) are "black boxes.” Neverthcless, it is convenicnt to assume that 
schedules of transaction automata obcy certain syntactic constraints. ‘Thus, transaction automata are required 


to preserve well-formedness, as defined below. 


We recursively define well-formedness for sequences of operations of transaction T. Namely, the empty 
schedule is well-formed. Also, if a = aa is a sequence of operations of T, where m is a single operation, 


then a is well-formed provided that a’ is well-formed, and the following hold. 


o Ifa is CREATE(T), then 
(i) there is no CREATE(T) in a’. 


e If 7 is COMMIT(T’,v) or ABORT(T) for a child T’ of T, then 


>Note that there is no provision for T to pass information to its child in this request. In a programming language, ‘I might be 
permitied to pass parameter valucs to a subtransaction. Although this may be a convenient descriptive aid, it is not necessary to include 
in it the underlying formal model. Instead, we consider transactions that have different input parameters to be different transactions. 


3Note that we do not include a REQUEST — ABORT operation for a transaction: we do not model the situation in which a transaction 
decides that its own cxistence is a mistake. Rather, we assign decisions to abort transactions to another component of the sysicm, the 
scheduler. In practice, the scheduler must have some power to decide to abort transactions, as when it detects deadlocks or failures. In 
ARGUS, transactions are permitted to request to abort: we regard this request simply as a “hint” to the scheduler, to restrict its allowable 
executions in a particular way. ‘This operation could be made explicit, constraining the scheduler to abort the requesting transaction, 
without substantively changing the model or results. 


G) REQUEST —CREATECT) appears in a? and 
(ii) there ts no return operation for T’ in a’, 


eo Ifo is REQUEST —CREATE(T’) fora child 1 of I, then 
(i) there is no REQUEST—CREATECI) in a 
(i) there is no REQUEST —COMMIT(T) in a’ and 
(iii) CREA TECH) appears in a’. 


e Ifa isa REFQUEST—COMMIT for'T, then 
(i) there is no REQUEST—COMMIT for'T in a’ and 
(ii) CREA'TECT) appears in @’. 


These restrictions are very basic; they simply say that a transaction docs not get created more than once, 
docs not receive repeated notification of the fates of its children, docs not reccive conflicting information 
about the fates of its children, and does not receive information about the fate of any child whose creation it 
has not requested; also, a transaction docs not perform any output opcrations before it has been created or 
after it has requested to commit, and does not request the creation of the same child more than once. Except 
for these minimal conditions, there are no restrictions on allowable transaction behavior. For example, the 
model allows a transaction to request to commit without discovering the fate of all subtransactions whose 
creation it has requested. Also, a transaction can request creation of new subtransactions at any time, without 
regard to its state of knowledge about subtransactions whose creation it has previously requested. Particular 
programming languages may choose to impose additional restrictions on transaction behavior. (An example is 
ARGUS, which suspends activity in transactions until subtransactions complete.) However, our results do not 


require such restrictions. 


The following casy lemma summarizes the propertics of well-formed sequences of transaction operations. 


Lemma 5: |.et a be a well-formed sequence of operations of transaction ‘I’. ‘Then the following 
conditions hold. 


1. The first operation of a is a CREATE(T) operation, and there are no other CREATE 
opcrations. 


2. If a REQUEST—COMMIT operation occurs in a, then there are no later output 
operations in a. 


3. There is at most onc REQUEST —CREATE(T’) operation for cach child T of T, in a. 


4. Every return operation in @ has a preceding REQUEST—CREATE operation in a@ for the 
same child transaction. 


3.2. Basic Objects 

Recall that 1/O automata are associated with non-access transactions only. Since access transactions model 
abstract operations on shared data objects, we associate a single 1/O automaton with cach object, rather than 
one for each access. ‘The operations for cach object are just the CREATE and REQUEST— COMMIT 
operations for all the corresponding access transactions, Although we give these operations the same names as 
the operations of non-access transactions, it is helpful to think of the operations of access transactions in other 
terms also: a CREATE corresponds to an invocation of an operation on the object, while a 
REQUEST— COMMIT: corresponds to a response by the object to an invocation. Actually, these CREATE 
and REQUEST— COMMIT opcrations generalize the usual invocations and responses in that our operations — 
carry with them a designation of the position of the access in the transaction tree. We depart from the 
traditional notational distinction between creation of subtransactions and invocations on objects, since the 
common terminology for access and non-access transactions is of great bencfit in unifying the statements and 


proofs of our results. ‘Thus, a basic object X is modelled as an automaton, with the following operations. 


Input operations: 
CREATE(T), for T in accesses(X) 


Output operations: 
REQUEST—COMMITCT,v), for T in accesses(X) 


‘The CREATE operation is an invocation of an access to the object, while the REQUEST—COMMIT is a 


return of a valuc in response to such an invocation. 


As with transactions, while specific objects are Icft largely unspecified, it is convenicnt to require that 
schedules of basic objects satisfy certain syntactic conditions. ‘Thus, cach basic object is required to preserve 


well-formedness, defined below. 


Let a be a sequence of operations of basic object X. Then an access T to X is said to be pending in a 
provided that there is a CREATE(T), but no REQUEST—COMM IT for T, in a. We define well-formedness 
for sequences of operations of basic objects recursively. Namely, the empty schedule is well-formed. Also, if 
a = a'n is a scquence of opcrations of basic object X, where @ is a single operation, then a is well-formed 


provided that a’ is well-formed, and the following hold. 


e If 7 is CREATECT), then 
(i) there is no CREATECT) in a’, and 
(ii) there are no pending accesses in a’. 


e If 7 is REQUEST —COMMIT for T, then 
(i) there is no REQUEST—COMMIT for T in a’, and 
(ii) CREATECT) appears in a’. 
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These restrictions simply say that the same access docs not get created more than once, nor does a creation 
of a new access occur at a basic object before the previous access has completed (i.c. requested to commit); 
also, a basic object docs not respond more than once to any access, and only responds to accesses that have 


previously been created. 


‘The following easy lemma summarizes the properties of well-formed sequences of basic object operations. 


Lemma 6: [ct a be a well-formed sequence of operations of basic object X. ‘Then @ consists of 
alternating CREATE and REQUEST —COMMIT operations, starting with a CREATE, and with 
each consecutive (CREA TE,REQUEST—COMMI1) pair having a common transaction. 


3.3. Serial Scheduler 

The third kind of component in a scrial system is the serial scheduler. ‘he scrial scheduler is also modelled 
as an automaton. ‘The transactions and basic objects have been specified to be any 1/O automata whose 
operations and behavior satisfy simple syntactic restrictions. ‘he serial scheduler, however, is a fully specified 
automaton, particular to cach system type. It runs transactions according to a depth-first traversal of the 
transaction tree. ‘The serial scheduler can choose nondcterministically to abort any transaction after its parent 
has requested its creation, as long as the transaction has not actually been created. In the context of this 
scheduler, the "semantics" of an ABOR'I(T) operation are that transaction ‘I was never created. ‘The 


operations of the scrial scheduler are as follows. 


Input Opcrations: 
REQUEST —CREATKT) 
REQUEST—COMMITCE,y) 
Output Opcrations: 
CREATE(T) 
COMMITCT.v) 
ABOR'(T) 


The REQUEST—CREATE and REQUEST—COMMIT inputs are intended to be identified with the 
corresponding outputs of transaction and object automata, and correspondingly for the CREATE, COMMIT 
and ABORT output operations. Each state s of the scrial schcduler consists of four sets: 
create — requested(s), created(s), commit—requested(s), and returned(s). The sct commit—requested(s) is a 


set of (transaction,valuc) pairs. ‘The others are scts of transactions. ‘There is exactly onc initial state, in which 


the set create — requested is {Ty}. and the other sets are empty. 


The transition relation consists of exactly those triples (s’.2,s) satisfying the pre- and postconditions below, 
where 7 is the indicated operation. For brevity, we include in the postconditions only those conditions on the 


state s which may change with the opcration. If acomponcnt of s is not mentioned in the postcondition, (such 


as returned(s) in the postcondition for REQUEST —CREATECT)), it is implicit that the sct is the same ins’ 
and s (that returned(s’) = returned(s). in this example). Note that here, as clsewhere, we have tricd to specify 
the component as nondeterministically as possible, in order to achieve the greatest possible gencrality for our 


results. 


e REQUEST —CREATECP) 
Postcondition: 
create — requestcd(s) = create — requested(s’) U {1} 


e REQUEST—COMMII(T,y) 
Postcondition: 
commit — requested(s) = commit—requested(s’) U {(‘E,v)} 


e CREATECT) 
Precondition: 
'l’ € create — requested(s’) - createdés’) 
siblings(l) M created(s’) C returned(s’) 
Postcondition: 
created(s) = created(s’) U {T} 


e COMMIT(T,v) 
Precondition: 
(Iv) € commit — requested(s’) 
TY € returned(s’) 
children(T) M create — requested(s’) C rcturned(s’) 
Postcondition: 
returned(s) = rcturned(s’) U {T} 


e ABORT(T) 
Precondition: 
T € create — requestcd(s’) - created(s’) 
siblings(1) N created(s’) € returned(s’) 
Postcondition: 
crcated(s) = creatcd(s’) U {T} 
returned(s) = rcturned(s’) U {T} 


The input operations, REQUEST—CREATE and REQUEST—COMMIT, simply result in the request 
being recorded. A CREATE operation can only occur if a corresponding REQUEST—CREATE has 
occurred and the CREATE has not already occurred. ‘The second precondiition on the CREATE operation 
says that the scrial scheduler docs not create a transaction until all its previously created sibling wansactions 
have returned. ‘I'hat is, siblings are run scquentially. ‘The precondition on the COMMIT operation says that 
the scheduler docs not allow a transaction to commit to its parent until its children have returned. The 
precondition on the ABORT opcration says that the scheduler does not abort a transaction while there is 
activity going on on behalf of any of its siblings. ‘That is, abortcd transactions are run sequentially with 


respect to their siblings. ‘he next lemma relates a schedule of the serial scheduler to the state which results 
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from applying that schedule. 
Lenina 7: Let a be a schedule of the serial scheduler, and Iet s be a state which can result from 
applying a@ to the initial state. ‘Then the following conditions are true. 


1. 'P is in create —requested(s) exactly if Il = Ty or a contains a REQUEST —CREATICT) 
operation, 


2.'T is in created(s) exactly if a contains cither a CREA TE(T) or ABOR TCP) operation. 


3.(T\v) is in commit—requested(s) exactly if @ contains a REQUEST—COMMII(T,y) 
operation. 


4. Tis in returned(s) exactly if a contains a return operation for T. 


3.4. Serial Systems and Serial Schedules 
In this subsection, we define serial systems preciscly and provide some uscful terminology for talking about 


them. 


The composition of transactions with basic objects and the serial scheduler for a given system type is called 
a serial system. Wefine the serial operations to be those operations which occur in the scrial system: 
REQUEST — CREATES, REQUEST— COMMITS, CREATES, COMMITS and ABORTS. ‘The schedules 
of a scrial system are called serial schedules. ‘he non-access transactions and basic objects are called the 
system primitives. (Recall that cach basic object is an automaton corresponding to a sct of access transactions. 


‘Thus, individual access transactions are not considered to be primitives.) 


Recall that the operations of the basic objects have the same syntax as transaction opcrations. It is 
convenient to refer to CREATE(T) and REQUEST—COMMI'T(I), when T is an access to basic object X, 
both as opcrations of transaction ‘T and of object X. To avoid confusion, it is important to remember that 


there is no transaction automaton associated with any access operation. 


For any scrial operation a, we define transaction(m) to be the transaction at which the opcration occurs. 
(For CREATE(T) operations and REQUEST—COMMIT opcrations for ‘T, the transaction is T, while for 
REQUEST~CREATE(T) opcrations, and COMMIT and ABORT operations for T, the transaction is 
parent(T).) For a sequence a of serial operations, transaction(a) is the set of transactions of the operations in 


a. 


Two sequences of serial operations, a and a’, are said to be equivalent provided that they consist of the 
same operations, and a|P = a’|P for cach primitive P. Obviously, this yiclds an cquivalence relation on 


sequences of serial operations. 
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We Ict afl denote the subsequence of @ consisting of operations whose transaction is ‘I’, even if T is an 
access. (This is an extension of the previous definition of afl, as accesses are not component automata of the 


serial system.) 


I.ct a be a sequence of serial operations. We say that a transaction T is Jive in a provided that a 
CREATEC?), but no COMMITCH, vy) or ABOR'TCT), occurs in a. We say that transaction I” is visible to Tin a 
provided that for cach ancestor ‘I of ‘1° which is a proper descendant of tca(1J1"), some COMMIECE’v) 
occurs in a. (In particular, any ancestor of ‘IT’ is visible to ‘Tin @.) For sequence @ and transaction 'T, Iet 
visible(a,T) be the subsequence of @ consisting of operations whose transactions are visible to 'T in a. (These 


include access transactions ‘I”.) We say that transaction 'T’ sees everything in a provided that visible(a,T) = a. 


This is the same definition of visibility as appears, in a different model, in [ly]. Visibility captures an 
intuitive notion suggested by the name: the transactions visible to a transaction ‘I’ in @ are those whose effects 
‘lis permitted to "sec" in a. If transaction I” is visible to transaction ‘T in a, it means that descendants of T 
may have passed to 'T’ information about I”, obtained by accessing objects that were previously accessed by 


descendants of I”. 


If @ is a sequence of operations, not necessarily all serial, then define scrial(a) to be the subsequence of a 
consisting of the scrial operations. We say that I is /ive in a provided that it is live in scrial(a). We say that I” 
is visible to T in @ if 1" is visible to T in serial(a), and define visible(a@,I') to be visible(scrial(a),1'). Also, T 
sees everything in a provided that T secs everything in scrial(a). Similarly, define transaction(a) = 


transaction(scrial(a)). 


A sequence a of scrial operations is said to be well-formed if its projection at every primitive is well-formed. 


3.5. Correctness Condition 

We use serial schedules as the basis of our correctness definitions. Namely, we say that a sequence of 
operations is serially correct for a primitive P provided that its projection on P is identical to the projection on 
P of some scrial schedule. We say that any sequence of operations is serially correct if it is serially correct for 


every non-access transaction. That is, a “looks like” a serial schedule to every non-access transaction. 


Jn the remainder of this paper, we define two systems: concurrent systems and weak concurrent systems. 
We show that schedules of concurrent systems are scrially correct, and that schedules of weak concurrent 


systems are scrially correct for To 


‘Thus, we use the serial scheduler as a way of describing desirable behavior, just as scrial schedules describe 
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desirable behavior in more classical concurrency control settings (those without nesting). “Phen scrial 


correctness plays the role in our theory that scrializability plays in classical settings. 


Motivation for our use of serial schedules to define correctness derives from the simple behavior of the 
scrial scheduler, which determines the sequence of interactions between the primitives. Each transaction T is 
created only after parent(!) requests it, no siblings of ‘Tare created until ‘T has returned, ‘Tis not committed 
until cach of its requested children has itself returned, and ‘T is not aborted until cach of its created siblings 
has returned. ‘The result is a depth-first traversal of the transaction tree, with requests flowing down and 
responses flowing up. We believe this depth-first traversal to be a natural notion of correctness which 
corresponds preciscly to the intuition of how nested transaction systems ought to behave. Furthermore, it is a 
natural generalization of scrializability, the correctness condition gencrally chosen for classical transaction 


systems. 


Scrial correctness is a condition which guarantees to implementors of transactions that their code will 
encounter only situations which can arise in scrial executions. Correctness for Ty is a natural alternative, 
which guarantees only that the external world will encounter only situations which can arise in scrial 
executions. This condition permits less constrained implementations, in that schedulers in such systems necd 
not insure that orphans sce consistent data. On the other hand, in such systems the authors of transactions 
must insure that their programs bchave well even if they sec inconsistencies. (Kor example, orphans that sce 
inconsistent data should not consume too many system resources, garble data beyond repair, dispense drugs 
or initiate military hostilities.) We hope this work will provide a tool for exploring the inherent costs of 


different correctness conditions such as these. 


Note that our correctness conditions are defined at the transaction interface only, and do not constrain the 
object interface. We believe that this makes the conditions more mcaningful to users, and more likely to 
suffice for a large varicty of algorithms, which may use a varicty of back-out, locking or version schemes to 
implement objects. Previous work has focussed on correctness conditions at the object interface [EGLT, ctc.]. 
While we belicve that object interface conditions are important, their proper role in the theory is not to serve 
as the basic correctness condition. Rather, they are uscful as intermediate conditions for proving correctness 
of particular implementations: such conditions can be shown to be sufficient, in combination with an 
appropriate scheduler, to ensure our correctness condition at the transaction interface. This observation is an 
important unifying contribution of our work. Our current rescarch is focussing on demonstrating the 


uscfulness of this approach, for a varicty of object interface correctness conditions. 


The serial correctness condition says that a schcdule @ must look like a scrial schedule to cach non-access 


transaction; this allows for the possibility that a might look like different scrial schedules to different non- 
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access transactions. ‘This condition may at first seem to be too weak. It may scem that we should require that 
all transactions see a projection of the sane serial schedule. Bul this stronger condition is not satisfied by most 
of the known concurrency control algorithms. {tis true that stronger conditions than ours can sometimes be 
proved, but such conditions are more complicated to state, and it is not yet clear which such conditions are 


most interesting. 


‘The serial correctness condition is really not as weak as it may sccm at first because ‘I’, the root transaction, 
is included among the transactions to which a must appear scrial. As discussed above, transaction To can be 
thought of as modelling the environment in which the rest of the transaction system runs. — [ts 
REQUEST— CREATE opcrations correspond to the invocation of top-level transactions, while its COMMIT 
and ABORT operations correspond to return values and external cffects of those transactions. Since a's 
projection on lp must be serial, the environment of the transaction system will sce only results that could arise 
in a scrial execution. Indeed, this is the justification of the correctness condition for the weak concurrent 


system, whose schedules are shown to be correct for ‘Ty, but not necessarily for any other transaction. 


It is possible to use a different serial scheduler as a basis for correctness conditions. For example, the 
scheduler might delay creating one sibling until another requests to return, rather than until it actually returns 
to the parent [We2]. Such a scheduler would provide Icss information to the parent about the actual order in 
which its children are executed, and consequently provide more freedom for concurrent schedulers to 
schedule various events. ‘Timestamp-bascd systems such as [R] may support this weaker correctness 


condition, rather than the one described above, but this remains to be studied. 


Our approach is really a general technique for studying opcrating system algorithms. A simple, intuitive 
and inefficient algorithm (automaton) is used to specify a "contract" between the uscrs and implementor of 
an operating system. The uscr is guaranteed that applications (transactions, in our work) which are correct 
when run with the simple algorithm will also be correct when run with the actual operating system, which 
presumably will be more efficient. On the other hand, the implementor also has a formal and intuitive 


specification of the user interface. 


3.6. Properties of Serial Systems 

In this subsection, we prove a number of lemmas about the behavior of scrial systems. ‘They are collected 
here for reference later in this paper and in future work. Most of the lemmas describe properties that are 
quite casy to understand and bclicve, and the corresponding proofs are very straightforward. In the last 
paragraph of this subsection, there are some spccialized lemmas that are somewhat more difficult. These are 


used in the proof of the main theorem in Scction 7. 
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3.6.1. Fundamental Properties of Visibility 
The first few lemmas give fundamental properties of visibility in sequences of serial operations. In this 
paragraph, we do not even require that the sequences be schedules of scrial systems, but only that they be 


sequences of serial operations. The proots of these lemmas are straightforward from the definitions. 


Lemma 8: [ct a be a sequence of scrial operations, and ‘V.'I” and I" transactions. 
1. HFT is a descendant of I, then 'T is visible to ‘T” in a. 
2. I" is visible to Tin @ if and only if'T’ is visible to Ica(T,1’) in a. 
3. If TP" is visible to ‘Il in a and I” is visible to ‘Tin a, then T” is visible to T in a. 
4. 1f 1" is a descendant of 1 and ‘t” is visible to T in a, then 'T”’ is visible tol” in a. 
5. If I” is a descendant of T and I” is visible to T” in a, then T is visible to T” in a. 


6. 1f T° is a proper descendant of I, I” is visible to 1” in a, but TF” is not visible to T in a, then 
‘Tl is a descendant of the child of I which is an ancestor of IT”. 


Lemma 9: |.ct a and B be sequences of scrial operations, with B a subsequence of a. 


1. If transaction ‘I’ is visible to transaction I” in B, then it is visible to transaction T° in a. 


2. If operation a is in visible(B,1), then it is in visible(a,T). 


Lemma 10: Let a, a’, B and B’ be sequences of serial operations, and Iet T and 1° be 
transactions. 


1. If is equivalent to a’, and IT” is visible to T in a, then T is visible to T in a’. 

2. If a is cquivalent to a’, then visible(a, 1’) is equivalent to visible(a’, I). 

3. If B is cquivalent to B’, then a - B = a- B’. 

4. If a is equivalent to a’, and B is equivalent to 8’, then a - B is equivalent to a’ - B’. 
5. If B = visible(a,T), then T secs everything in B. 

6. If B is equivalent to visibic(a,T), then T sees everything in B. 

7.1f 8 = visible(a,T) and T is visible to T in a, then visible(8.1") = visible(a,T). 


8. If B is equivalent to visible(a,1'), B’ is equivalent to visible(a,1T”), and T’ is visible to T in a, 
then f’ is equivalent to visible(B,T’). 


Lemma 11: Let a be a sequence of scrial operations, and Ict T and T be transactions. Then 
Lemma 12: |.ct aw be a sequence of serial operations, where 7 is a single operation. Let T be a 


transaction and assume that transaction(7) is visible to ‘lf in aw. Assume that a is nota COMMIT 
operation. ‘Then visible(agv.1) = visibte(a, Ta. 


3.6.2. Operations in Serial Schedules 
‘The lemmas in this paragraph describe the kinds and orders of operations that can occur in well-formed 
scrial schedules. In the next paragraph, we show that all serial schedules are well-formed, so that all these 
properties actually follow just from the fact that the schedules are serial. 
Lemma 13: Lect @ be a well-formed serial schedule, and Iet 1 # ‘Ty be a transaction. 


lf @ contains any operation with transaction ‘T, then a contains a 
REQUEST—CREATECT). 


2. 1f a contains a COMMIT for ‘T, then @ contains a REQUEST—COMMIT for T, a 
CREATECL) and a REQUFST—CREATECP). 


3. If a contains an ABOR'T'(T), then @ contains a REQUEST — CREATE(T). 


Proof: Straightforward from well-formedness and the scheduler preconditions, # 


Lemma 14: Let a be a well-formed scriat schedule, and ‘I! a transaction. Assume that some 
descendant of T is in transaction(a). ‘Then the following hold. 


1. CREATECT) occurs in a. 
2. IFT # I, then REQUEST —CREATE(T) occurs in a. 


Proof: 1. By induction on the length of a. ‘The basis is casy. Let a = a’m, where m is a single 
operation, and assume that the result holds for a’. Let ‘I’ = transaction(q), and Ict ‘I’ be any 
ancestor of I”. We must show that CREATE(T’) occurs in a. 


Because a is well-formed, CREATE(I’) occurs in a. If IT = T°, we are done. Otherwise, 
Lemma 13 implies that REQUES'T—CREATECT’) occurs in a. ‘This occurs at parent(I’), which is 
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2. By part 1. and Lemma 13. 8 

Lemma 15: Let a be a scrial schedule, and Iet T be a transaction. Then a cannot contain both a 
CREA TE(T) and an ABOR'I(T) operation. 

Proof: By the scheduler preconditions. & 

Lemma 16: [ct a be a well-formed scrial schedule, and Iet T be a transaction. If ABORT(T) 
occurs in a, then a contains no operations whose transactions are descendants of T. 


erry tT 


But Lemma 15 yields a contradiction. & 
Lemma 17: Let a be a well-formed serial schedule, and Ict T # Ty be a transaction. 
then parent(T) is live in a. 
2. If T is live in a, then parent(T) is live in a. 


3. 1f a contains a REQUEST-CREATE(T) but docs not contain a CREATE(T) or an 
ABORT(T), then parent(T) is live in a. 


Proof: 


1. Well-formedness implics that the REQUEST —CREATECT) is preceded in @ by a 
CREATE(parent(l)). Suppose that parent(1) is not live in a. ‘Then a return operation for 
parent(l’) occurs in a. By Lemma 15, ABOR T(parent(F)) cannot appear in a. ‘Thus, a 
COMMIFE opcration for parent(l) must appear in a. ‘This COMMIT operation for 
parent(T) must be preceded by a REQUEST —COMMIETP for parent(l), by the scheduler 
preconditions. By well-formedness, the REQUEST — COMMIT for parent(l) must follow 
the REQUEST—CREATECL) operation, so that the COMMIT for parent(l’) follows the 
REQUEST—CREATECT) operation. ‘Then by the scheduler preconditions for the 
COMMIT operation, there must be a return operation for ‘I’ in a, a contradiction. 


at Byatt 


REQUEST—CREATE(1) occurs in a. ‘The result then follows from part 1. 


. Since there is no CREATEC(T) in a@, there can be no REQUEST'—COMMIT for 'T, by 
well-formedness. ‘Then there can be no COMMIT for T, by the scheduler preconditions. 
The result follows from part 1. 


had 


| 
Lemma 18: L.ct a be a well-formed scrial schedule, and Ict T be a transaction. 


then any proper ancestor of T is live in a. 
2. If T is live in a, then any ancestor of T is live in a. 


3. 1f a contains a REQUEST—CREATE(T) but docs not contain a CREATE(T) or an 
ABOR F(T), then any proper ancestor of T is live in a. 


Proof: By repeated use of Lemma 17. § 


Lemma 19: [ct a be a well-formed serial schedule, and Ict T and ‘I” be transactions with T a 
descendant of 'l’. Assume that there is a COMMIT opcration for T in a. 


1. Ifa REQUEST—CREATE(T) occurs in a, then there is a return operation for 'T’ in a. 


2. If I” is in transaction(a), then there is a COMMIT opcration for 'T’ in a. 
Proof: 


1. By Lemma 18. 


2. Lemma 13 implics that REQUEST—CREATE(T’) occurs in a. Part 1 then implies that 
there Is a return opcration for I” in a. Since ‘TP is in transaction(a), Lemma 16 implies that 
there cannot be an ABOR1(I") in a. Thus, there isa COMMIT for T’ in a. 


Lemma 20: Let a be a well-formed scrial schedule. 
(fa return operation for 'T is in a, then it follows all operations in a whose transaction is T. 


Proof: Lemma 16 implies the result if an ABORT(T) occurs in a. So assume that a COMMIT 
for 'P occurs in a. This must be preceded by a REQUESIT—COMMIT for 'T, by scheduler 
preconditions. Well-formcdness implics that the REQUEST—COMMIT is preceded by a 
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CREATECT). and is not followed by any output operations of T. Thus, the only operations of T 
that could follow the REQUEST—COMMITE are return operations for children of ‘VY. Let Tl’ be a 
child of T for which a return operation occurs in a. By scheduler preconditions, there is only one 
return operation for Pin a. By Lemma 13, @ also contains a REQUEST —CREATECI’). Since 
this is an output operation of T, it precedes the REQUEST—-COMMIT for 'P, and hence precedes 
the COMMIT for ‘l. ‘Phen the scheduler preconditions imply that the return operation for I" 
precedes the COMMIT for‘. ff 

Lemma 21: [ct a be a well-formed serial schedule. 
If a return operation for ‘Tis in a, then it follows all operations in a@ whose transactions are 
descendants of T. 

Proof: Since a return opcration for ‘l’ occurs in a, we have ‘I # ‘Ty. Let 'P be a descendant of T, 
and assume for the sake of obtaining a contradiction that an operation @ with transaction(a) = T° 
occurs after the return for’ in a. L.ct a’ be the prefix of a preceding a. 


!.cmma 16 implies the result if an ABOR'E(T) occurs in a. So assume that a COMMIT for T 
occurs in a. By Lemma 13, a’ contains a REQUEST —CREATECL) operation. ‘Then Lemma 19 
implies that a’ contains a return operation for ‘I’. But then the well-formed schedule a’ contains 
a return for I” followed by an operation of 1’, which contradicts |.cmma 20. § 

Lemma 22: |.ct a be a well-formed serial schedule. If f is a pending access in aX, then T is live 
in a. 

Proof: If ‘Tis a pending access in a]X, then a CREATE(T) occurs in a, but no 
REQUEST—COMMfEF for 'T occurs in a. ‘Thus, by the scheduler preconditions, no COMMIT 
for lcan occur ina. Ef 


Lemma 23: Let a be a well-formed scrial schedule, and Iet 'f and ‘I” be distinct transactions live 
in a. Then the following are true. 


1. T and IT” are not siblings. 


2. Either T is an ancestor of I” or vice versa. 
Proof: 


1. Assume the contrary. Assume without loss of gencrality that CREATE(T) precedes 
CREATE(1") in a. Then the scheduler preconditions for the CREATE(I’) operation 
imply that a return opcration for ‘T occurs in a. ‘This contradicts the assumption that T is 
live in a. 


2. By part 1 and Lemma 18. 


3.6.3. Well-Formedness 
Now we show that all serial schedules are well-formed. It follows that all the propertics proved in the 
previous paragraph for well-formed scrial schedules are actually true for all scrial schedules. Subsequently, 
we will use these properties without explicitly mentioning well-formedness. 
Lemma 24: L.ct a be a serial schedule. ‘Then @ is well-formed. 


Proof: By induction on the length of schedules. The base, length = 0, is trivial. Suppose that 
am is a scrial schedule, and assume that a@ is well-formed. If is an output of a primitive P, then 
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am|P is well-formed because P preserves well-formedness, and so aa is well-formed. So assume 
that w is an input Co a primitive P. It suffices to show that ag|P is well-formed. ‘Phere are four 
cases. 


(1) 7 is CREATECH) and Tis a non-access transaction. 
The scheduler preconditions insure that CREA TE(T) docs not appear in a. 


(2) 7 is COMMIT(CT.v) for some transaction ‘T and valuc v. 
Then @ is an input to transaction parent(l) = ‘T. ‘The scheduler preconditions imply that @ 
contains a REQUEST—COMMII(I.v), and so Lemma 13 implies that @ contains a 
REQUEST—CREATE(T). Also, the scheduler preconditions imply that no return operation for 
T occurs in a. 


(3) 7 is ABOR'I(T) for some transaction ‘T. 
Then @ is an input to transaction parent(lT) = ‘I’. ‘The scheduler preconditions imply that a 
contains a REQUEST — CREATE(TP), but no return operation for’). 


(4) a is CREATECT) and T is an access to basic object X. 

By the scheduler preconditions, no CREATECY) or ABORTCE) appears in a, but a 
REQUEST—CREATECT) appears in a. Assume for the sake of deriving a contradiction that I” is 
a pending access in a|X. ‘Phen |.cmma 22 implies that I” is live in a. Also, Lemma 17 implics that 
parent(l) is live in a. ‘Then !.cmma 23 implics that one of ‘I’ or parent(l) is an ancestor of the 
other: since ‘T and ‘IP’ are both Icaves of the transaction tree, the only possibility is that parent(l) is 
a proper ancestor of T”. Let'l” be the sibling of I which is an ancestor of I”. ‘Then I” is live in a, 
by Lemma 18. ‘hat is, there is a CREATE(!"), but no COMMIT for ‘T” in a. But this 
contradicts the scheduler preconditions for a. ‘VWherefore, there is no pending access in a|X. § 


3.6.4. Visibility and Serial Schedules 


In this paragraph. we prove interesting lemmas about visibility in scrial schedules. 

Lemma 25: ct a be a serial schedule, and w an opcration in a. ‘Then transaction(m) is visible in 
a to some transaction which is live in a. 

Proof: I.ct T = transaction(z). Since @ is not cmpty, Ty is live in a. L.ct'I” be the least ancestor 
of 'T which is live in a. ‘The proof is by induction on the distance from T" to T. If T = ‘T, the 
result is trivial. So assume that T # ‘I’. ‘Then COMMIT‘(1) is in a, and so 'T is visible to parent(T) 
in a. Lemma 13 implics that a contains a REQUEST—CREATE(T) operation, which occurs at 
parent(l’). Then the inductive hypothesis implics that parcnt(T) is visible to 1°. Then T is visible 
to T by Lemma 8. & 

Lemma 26: 


1. Let @ be a serial schedule, T a transaction and X an object. Then visible(a,T)|X is a prefix 
of a|X. 


2. Let a be a scrial schedule, T a transaction and P a primitive. Then visible(a,1)|P is a prefix 
of a|P. 


Proof: 1. l.ct a and g be operations in a|X, with w preceding g, and @ an opcration in 
visible(a,T). Let a’ be the prefix of @ preceding g. Let 1? = transaction(y) and I” = 
transaction(@). Since is cither a CREATE or a REQUEST—COMMIT for T’, well-formedness 
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of a implies that I" is live in ap. ‘Thus, by Lemma 23, the only live transactions in ap are 
ancestors of I. By Lemma 25, I” is visible to an ancestor of 1" in a’. and hence in a. By 
Lomma 8.1" is visible to IT’ in a. But ‘I’ is visible to Tin a, by assumption. Lemma 8 then 
implics that ‘I is visible to Tin @, which gives the result. 


2. Immediate from [.emma 11] and part 1. BF 

Lemma 27: Let a be a nonempty serial schedule. Let w be the last operation in a which is an 
outpul of the serial scheduler. ‘Then transaction(a) secs everything in a. 

Proof: Let‘ = transaction(a). We first show that ‘Tis live in a. Either a is a CREA TEC) or 
else it is a return operation for a child TT of ‘IT. In the latter case, Lemma 14 implies that 
CREATECT) also occurs in a. ‘hus, in cither case, CREA TE(T) occurs in a. Now, if a return 
operation for ‘T occurs in a, |.cmma 21 implics that it follows a, which is impossible. ‘Thus, no 
return opcration for T occurs in a. It follows that 'l’ is live in @. 


Then Lemma 23 implics that the only other transactions that are live in a must be ancestors or 
descendants of 'T. We claim that no proper descendants of ‘I are live in a. So assume for the sake 
of obtaining a contradiction that U is a proper descendant of ‘Il which is live in a. ‘Then U is a 
descendant of a child V of T, and V is live in a, by Lemma 18. [ct a be the prefix of a preceding 
m. ‘here are three cases. 


(1) w is CREATE(T). 
‘Then lemma 14 yiclds a contradiction. 


(2) x isa COMMIT opcration for ‘I’, a child of T. 
Then ‘I’ # V, since I” is not live in a. But'l” and V arc both live in a’, which contradicts Lemma 


23. 


(3) 7 isan ABORT(T), for child T’ of T. 
Then I” # V, since 'T’ is not live in a. But V is live in a’. But then the scheduler preconditions for 


7 arc not satisficd, a contradiction. 


‘Thus, no descendants arc live in a, so the only transactions that are live in @ are anccstors of 
T. Now Iet @ be any operation in a. Lemma 25 implies that transaction(@) is visible in a to some 
ancestor of I’, and hence to 'T. & 

Lemma 28: Let @ be a serial schedule, and T a transaction. Then visible(a,T) is a serial 
schedule. 

Proof: We proceed by induction on the Iength of a. The basis, length 0, is trivial. Lect a = a’z, 
where q is a single operation. Fix transaction T, and Ict T = transaction(2). If T is not visible to 
T in a, then visible(a.1) = visible(a’,I'), and the result is truce by inductive hypothesis. So assume 
that’ is visible to T in a. 


If w is an output operation of a primitive P, then visible(a,T)|P is a prefix of a|P, by Lemma 26, 
and thus is a schedule of P. By the inductive hypothesis, visible(a’,T) is a scrial schedule. Also, 
visible(a,f) = visible(a’/1)a by Lemma 12. Then Lemma 4 shows that visible(a@,T) is a serial 
schedule. 


On the other hand, if @ is an output operation of the scheduler, then [.emma 27 implies that T° 
sees everything in a. But since T" is visible to T in a, it follows that T sees everything in a. Thus, 
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visible(a, tT) = a, ascrial schedule. I 


3.6.5. Reordering and Combining Scrial Schedules 
In this paragraph, we describe ways in which scrial schedules can be modified and combined to yicld other 


scrial schedules. ‘These lemmas are used in the proof of the main theorem, in Section 7. 
Lemma 29: [ct a and a’ be two cquivalent scrial schedules. If B is a sequence of serial 
operations such that a is a serial schedule, then a’ is a serial schedule, and is equivalent to aB. 
Proof: Equivalence is trivial, The fact that a’B is a serial schedule follows because the 
preconditions of the serial scheduler depend only upon the presence of previous operations, not 
their order. Wl 


‘The next lemma says that any serial schedule can be transformed by moving all the operations visible to any 
particular transaction to the beginning of the schedule, and the result is another serial schedule. ‘This lemma 
can be thought of as describing a kind of "canonical form" for a serial schedule, with respect to a particular 


transaction. 
Lemma 30: Lct a be a serial schedule, and ‘lV any transaction. Let 8 = visible(a.T). Then Bla - 
B) is equivalent to @ and is scrial. 
Proof: Let a’ = B(a - B). If P is any primitive, then [.cmma 26 implies that A|P is a prefix of 
a|P. ‘Thus, a” is equivalent to a. 


‘lo show that a is serial, we proceed by induction on its prefixes. By Lemma 28, £ is scrial, so 
we can use B as the basis. Lect ya be a prefix of a’, where @ is a scrial operation in a - B and y isa 
serial schedule. If 7 is an output operation of a primitive P, then ya|P is a prefix of a'|P, = a|P 
by equivalence, which is a schedule of P. ‘Then |.emma 4 shows that yz is a scrial schedule. So 
assume that a is an output operation of the serial scheduler. 


I-ct s be the state of the scrial scheduler after y. Ict y's be the prefix of a ending in w, and lets’ 
be the state of the serial scheduler after y’. Then a is cnabled in s’. We must show that a is 
enabled ins. This suffices, by Lemma 4. 


Since every operation in y’ is also in y, it follows that each component set of s’ is a subsct of the 
corresponding sct of s. ‘There are three cases. 


(1) 2 is CREATE(T’) for some transaction T’. 
Then transaction(7) = T, and T is not visible to Tin a. Then T° € create—requested(s’) C 
create —requested(s). Also, it is casy to show that ‘l” € created(s). Now Ict U be in sibling(T) N 
created(s). If U € created(s’), then U € returned(s’) since 7 is enabied in s', C returned(s), as 
needed. So suppose that U € created(s’). ‘hen CREATE(U) occurs in B, so U is visible to T in a. 


Since a contains both CREATE(T’) and CREATE(U), Lemma 23 implics that a must contain a 
COMMIT for at Ieast one of ‘I? or U. If a contains aCOMMIT for U, then it occurs in B, so U € 
returned(s). On the other hand, if a contains a COMMIT for T’, then I” is visible to U in a, so 
Lemma 8 implies that T° is visible to Tin a@, a contradiction. 


(2) 7 is COMMIT(T’,v) for some transaction ‘T and value v. 
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Then transaction(a) is parent(l’), which is not visible to Toin a. Then (Iv) is in 
commit— requested(s’) Co commit— requested(s). Also, it is casy to show that ‘Tis not in 
returned(s). Now let U be in children(1") create —requested(s). ‘Then there is a 
REQUEST —-CREATE(U) in yo This REQUEST -CREATE(U) occurs at TP’) which cannot be 
visible to Tin @ since parent(!’) is not visible to Pin a. ‘Thus, the REQUEST —CREATE(U) 
docs not occur in B, so it occurs in y’. Since aw is enabled ins’, we have U € returned(s’) € 
returned(s). 


(3) 7 is ABOR'TCT’) for some transaction ‘T’. 
Then transaction(@) = parent(l’), and parent(l’) is not visible to T in a. Then TT € 
create — requested(s’) € create—requested(s). Also, it is easy to show that ‘I’ € created(s). Now 
let U € siblings(1") M created(s). ‘Then CREA TE(U) occurs in y. But CREATE(U) occurs at U, 
and U cannot be visible to T in @ since parent(U) = parent(l’) is not visible tol in a. ‘Therefore, 
CREATE(U) does not occur in B, so it occurs in y’. ‘Then U is in siblings(I") MN created(s’) C 
returned(s’) € returned(s). # 


The following lemma is an casy consequence of the preceding one. 

Lemma 31: Let a be a schedule of scrial operations, and Ict'l and ‘I’ be two transactions with T 
visible to Pin a. Let B and B be scrial schedules, such that B is equivalent to visible(a.T) and B” 
is cquivalent to visible(a, I"). Then B” = B'(B - B’) is cquivalent to B and serial. 

Proof: |.ct y = visible(B.1"). ‘Then y is scrial by Lemma 28. lemma 30 implies that y(B - y) is 
equivalent to B and scrial. |.cmma 10 implies that B° is equivalent to y, and thus that B- y = B - 
B’. Then Lemma 29 implics that 8” is equivalent to y(B - y) and scrial. ‘Thus, 8” is equivalent to 
B and scrial. § 


The next two lemmas are used in the proof of Theorem 68. Each describes a way of “cutting and pasting” 


two scrial schedules to yield a new scrial schedule. 
Lemma 32: [ct aB ,COMMIT(T.u) and aB, be two scrial schedules and T, ‘1” and T”’ three 
transactions such that the following conditions hold: 
(1) 'T’ is achild of T° and T is a descendant of I” but not of T, 
(2) I" sces everything in aB 
(3)'T’ sees everything in a8, 
Ya= visible(aB |. 1") = visible(aB,,1”) and 
(5) no basic object has operations in both B, and B,. 
Then af ;COMMIT(T’u)B, is a scrial schedule. 
Proof: Note first that if fT = T”, then B, is empty and the result is trivial. So assume that T # 
T". Then T is a descendant of a child U of 'T", and U # T. 


Any opcration in aB | whose transaction is not a descendant of T”, must be in visible(aB ,T") by 
Lemma 8. Similarly, any operation in aB, whose transaction is not a descendant of U, must be in 
visible(aB,.1™). ‘Thus, B , and B, contain only operations at descendants of I’ and U, respectively. 
Since I” and U are distinct siblings, and by assumption no objects have operations in both 8, and 
B,, it follows that no primitive has an operation occurring in both B, and B,. 


We proceed by induction on prefixes of aB COMMIT(T wB,. Let a’p be a prefix of 


a8 ,COMMIT(I",u)B,, with a’ a scrial schedule and @ a scrial operation. We use ap = 
aB COMMIT(I".u) as the basis, since aB COMMIT(T,u) is a scrial schedule by assumption. So 
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assume that a” = aB COMMIT(H.u)B for some sequence B*. ‘There are two cases, depending 
on whether @ is an output of a primitive or of the scrial scheduler. 


Suppose that @ is an output operation of a primitive P. “Then B COMMIT(I.y) contains no 
operations at P. Thus, ag|P = aB'p|P. which is a pretix of af,|P. which is a schedule of P since 
aB, is ascrial schedule. ‘Thus, a p|P is a schedule of P. ‘The result follows by Lemma 4. 


So suppose gy is an output of the serial scheduler. ‘Then transaction(g) = V for some 
descendant V of U. Lets be the state of the serial scheduler after a’, and lets’ be the state of the 
scrial scheduler after aB’. ‘Vhen the following relationships hold between s ands’. 


1. V € create — requested(s’) - created(s’) iff V € create — requested(s) - created(s) 


2. children(V) MN create — requested(s’) C returned(s’) iff children(V) M create — requested(s) 
C returned(s) 


3. (V.v) € commit — requested(s’) iff (V.v) € commit — requested(s) 
4. V € returned(s’) iff V € returned(s) 


5. siblings(V) A created(s’) C returned(s’) iff siblings(V) M created(s) C returned(s) 


Since the operations in B, arc all at descendants of I”, and those of B, are all at descendants of 
U, the first four biconditionals are immediate from |.emma 7. If V is a proper descendant of U, 
the last biconditional also follows. It remains to show that siblings(U) M created(s’) € returned(s’) 
iff siblings(U) M created(s) C returned(s). But any sibling of U created in a’ is created in a’, 
and the only sibling of U created in a’ and not af" is I’, and ‘IT’ € returned(s). ‘Thus, the claims 


are true. 


Since @ is enabled in s’, the claims above imply that » is also enabled in s. ‘The result follows. @ 


Lemma 33: Let aABORT(T) and af be two scrial schedules, and Iet 1, I” and T” be 
transactions, such that the following conditions hold: 
(1) Il’ is achild of 1” and I is a descendant of T” but not of T, 
(2) I sces everything in af, and 
(3) a = visible(a.1") = visible(aB.T”). 
Then aABORT(I’)£ is a serial schedule. 
Proof: Similar to, but somewhat simpler than, the proof of Lemma 32. &f 


4. Resilient Objects 

Having stated our correctness conditions, we are now ready to begin describing implementations and 
proving that they meet the requirements. ‘This section and the next are devoted to the description of a 
concurrent system which permits the abort of transactions that have performed steps. An important 
component of a concurrent system is a new kind of object called a “resilicnt object," which we introduce in 
this section. A resilient object is similar to a basic object, but it has the additional capability to undo 


operations of transactions that it discovers have aborted. 
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Resilient objects have no capabilities for managing concurrency: rather, they assume that concurrency 
control is handled externally (by lock manager components of the scheduler). ‘This section defines resilient 
objects and presents some of their properties. IL also digresses slightly from the main development by 
describing and proving correct a particular implementation of resilient objects. which are constructed by 
keeping multiple copies of corresponding basic objects. ‘Whe resilient object manages these copies as versions 
of the data object. Upon earning of an abort, the appropriate stored version is used in place of the current 


version. 


4.1. Definitions 

Resilicnt object R(X) mimics the behavior of basic object X, but has two additional input operations, 
INFORM —COMMIT—AT(X)OF(T) and INFORM—ABORT—AT(X)OF(T), for every transaction 
T. Upon receiving an INFORM —ABORT—AT(X)OF(T), R(X) erases any effects of accesses which are 


descendants of T. Vhis property is made formal as the “Resiliency Condition” below. 


R(X) has the following operations, which we call R(X operations. 


Input Operations: 
CREA'TECT), ‘Tan access to X 
INFORM —COMMIT—AT(X)OF(L) 
INFORM — ABORT — AT(X)OF(T) 


Output Operations: 
REQUEST—COMMIT(T,v), T an access to X 


In order to describe well-formedness for resilicnt objects, we require a technical definition for the set of 
transactions which are active after a sequence of R(X)-opcrations. Roughly speaking, the transactions which 
are active are those on whose behalf the object has carricd out some activity, but whose fate the object does 


not know. 


The definition is recursive on the Icngth of the sequence of R(X) operations. Namely, only Tp is active after 
the empty sequence. Let a = Ba, where is a single opcration, and Iect A and B denote the sets of active 
transactions after a and B, respectively. If @ is CREATE(T), then A = B U {T}. If w is a 
REQUEST—COMM IT for T, then A = B. If #7 is INFORM—COMMIT—AT(X)OF(T), and if T is in B, 
then A = (B- {T}) U {parent(T)}; if T is not in B, then A = B. If a is INFORM—ABORT-— AT(X)OF(T), 
then A = B- descendants(T). 


Now we define well-formedness for sequences of R(X) operations. Again, the definition is recursive. 


Namely, the empty schedule is well-formed. Also, if a = a'm is a sequence of R(X)-operations, then a is 
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well-formed provided that a’ is well-formed, and the following hold. 


e Ifa is CREA TECT), then 
(i) there is no CREA TEC) in a’; 
(it) all the transactions which are active after a’ are ancestors of T. 


@ Ifo isa REQUEST—COMMIT for’l, then 
(i) there is no REQUEST— COMMIT for Tin a’, and 
(ii) 1 is active after a’. 


e Ifa is INFORM —COMMIT—AT(X)OF(P), then 
(i) there is no INFORM — ABOR'T— ATCX)OF(L) in a’, and 
(ii) if 1 is an access to X, then a REQUEST —COMMIT for 'T occurs in a’. 


e Ifa is INFORM —ABORT—AT(X)OF(T), then 
(i) there is no INFORM —COMMIT— AT(X)OF(1T) in a’. 


An immediate consequence of these definitions is that the transactions active after any well-formed 
sequence of R(X)-operations @ are a subset of the ancestors of a single active transaction, which we denote 


Icast(a). 


For a a sequence of R(X)-opcrations, define undo(a) recursively as follows. Define undo(A) = A, where A 
is the empty sequence. Let a = Ba, where is a single operation. If 7 is a serial operation (a CREATE or a 
REQUEST—COMMIT), then undo{a) = undo(B)7. If 7 is INFORM—COMMIT—AT(X)OF(T), then 
undo(a) = undo(B). If a is INFORM—ABORT—AT(X)OF(T), then undo(a) is the result of climinating, 
from undo(f), all operations whose transactions are descendants of ‘1’. Note that undo({a) contains only serial 


operations. 


I.ct a@ be any sequence of R(X}opcerations, and let w be an operation in a of the form 
INFORM — ABORT— AT(X)OF(T). Then the scope of w in @ is the subsequence y of a@ consisting of 


operations climinated by w. 


Resiliency Condition 
Resilient object R(X) satisfies the resiliency condition if for every well-formed schedule a of R(X), undo(a@) is 


a schedule of basic object X. 
We require that resilient object R(X) preserve well-formedness and satisfy the resiliency condition. 


The resiliency condition is the correctness condition required by the concurrent schedulers at the object 
interface. The well-formedness requirement is a syntactic restriction, and the condition that undo{a) be a 


schedule of basic object X expresses the required semantic relationship between the resilient object and the 
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basic object it incorporates. ‘The important property which must be preserved is that the correctness condition 
at the resilient objects, together with the behavior of the concurrent scheduler, assures correctness at the 


transaction boundarics. 


4.2. Properties of Resilient Objects 
This subsection contains a collection of simple lemmas about the properties of well-formed sequences of 


R(X) operations. 


Lemma 34: |.ct aw be a well-formed sequence of R(X) operations, with wv a single operation. 
The following are truc. 


1. If @ is a scrial operation, then transaction(7) is active after aq. 
2. If 'T is an access active after a prefix of a but not after a, then 'T is not active after am. 


3. If isa REQUEST—COMMIT for 'T, then CREA'TECT) is the last scrial operation in a. 
Proof: 
1. Immediate from.the definition of active and well-formedness. 
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occurs, which can only happen once in a well-formed schedule. 


3. Suppose the last serial operation in a is yp, with p # CREATE(T). Lct transaction(g) = 
‘I’. By well-formedness, 'T # ‘T°. Also by well-formedness, T is active in a, so that 
CREATE(T) must occur in a, and so precedes y. By part (1), I is active following 
CREATE(T) and after 7, and ‘I” is active following g. But T cannot be active when » 
occurs, by well-formedness, contradicting part (2) of this lemma. 


Lemma 35: Lct a be a well-formed sequence of R(X) operations. I.ct T and T be accesses to X, 
with ‘IT # I”, and Iet w and @ be scrial operations with transactions '! and 1°, respectively. If 7 
precedes p in a, then between @ and q, there is cither an INFORM — ABORT— AT(X) for some 
ancestor of IT’, or else there are INFORM —COMMIT—AT(X)OF(U) operations for all ancestors 
U of T which are not ancestors of ‘I’, occurring in order from lowest to highest in the transaction 
tree ordering. 


Proof: By part 3 of Lemma 34 and well-formedness, we may assume that py = CREATE(T)). 
Lemma 34 implics that T is active immediatcly after 7. By well-formedness, before CREATE(T’) 
can occur, it must be that all transactions which arc active are ancestors of I”. There are only two 
ways in which this can happen. Onc possibility is that R(X) first reccives INFORM —COMMITS 
for all ancestors of ‘T up to Ica(I',I”), in order from lowest to highest in the transaction tree 
ordering. ‘The other possibility is that R(X) first reccives an INFORM— ABORT for an ancestor 
of T. 8 

Lemma 36: Let am be a well-formed sequence of R(X) operations, with w = 
INFORM —ABORT—AT(X)OF(T). Then undo(a7) is a prefix of undo(a). 

Proof: Suppose not. Then there is a subsequence py of two opcrations in undo(a), such that 
is in undo(az) and @ is not. Clearly, p and ¥ are scrial operations, transaction(p) is a descendant 
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of ‘land transaction(y) is not. Since g is not in the scope of an INFORM—ABORT in a, by 
lemma 35, there is an INFORM—COMMIT between and ~ for every proper descendant of 
Ica(transaction(p),transaction(y)) that is an ancestor of transaction(g), including T. ‘This 
contradicts the well-formedness of aw. 

Lemma 37: Let a be a well-formed sequence of R(X) operations, and tet Tbe any transaction 
active in a, other than f. ‘Phen undo(a) contains an operation » at a descendant I” of PT, which is 
followed in a by an INFORM—COMMITI for every ancestor of ‘IP’ which is a proper descendant 
of T. 

Proof: ‘he proof is by induction on a, with a trivial basis. [ct a@ = a’a, such that the lemma is 
truc for a’ and that 7 is a single operation. |ct ‘I be a transaction active after a. ‘There are four 
cases. 


Suppose aw is CREATEC(I™). ‘Then undo(a) = undo(a’)a. If T # ‘I, the result is immediate by 
the induction hypothesis, since ‘I’ is active after a’. If‘ = ‘I’, then the Iemma follows, with w = 


q. 


If isa REQUEST—COMMIT for a transaction TI, then undo(a) = undo(a’)a and the same 
transactions arc active in a and a’. ‘The result is immediate. 


Suppose a is an INFORM—COMMIT for a transaction ‘I’. ‘Then undo(a) = undofa’)a. If T 
is active after a’, the result is immediate. If'f is not active after a’, it follows that 'T = parent(‘l”). 
The result is immediate from the induction hypothesis. 


Suppose 7 is an INFORM—ABORT for a transaction U. Since 'T is active after a, it was active 
after a’ and U is not an ancestor of 'T. Let @ be the transaction of transaction ‘I” which follows 
from the inductive hypothesis applicd to T and a’. Since a is well-formed and a’ contains 
INFORM—COMMI's for every ancestor of I” up tol’, U is not an ancestor of I”. It follows that 
@ is in undo(a@) and the result holds. 

Lemma 38: [ct a be a well-formed scquence of R(X) operations, and Iet Ieast(a) = T. If 
und(a) is nonempty, then it ends in an operation of a descendant of T. 

Proof: If T = ‘Ty, the result is trivial, so assume otherwise. By the previous lemma, undo(a) 
contains an operation gy at a descendant of I’. Without loss of generality, assume that @ is the last 
operation in undo{a) at a descendant of ‘T. If any other operation w followed gy in undo(a@), by 
Lemma 35 @ would contain INFORM—COMMITs for every ancestor of transaction(@) up to 
Ica(transaction(@),transaction(a )), which includes T. Then I is not active in a, acontradiction. 

Lemma 39: [ect aw be a well-formed sequence of R(X) operations, with w = 
INFORM—ABORT—AT(X)OF(T). If T is not an ancestor of Icast(a), then undo(aw) = 
undo(a). 

Proof: Suppose that T is not an ancestor of least(a) and that undo(aw) # undo{a). Then 
undo(a@) contains a serial operation @ at a descendant T° of 'T. By Lemma 38, » is followed in 
undo(a) by an operation at a descendant of least(a). By Iemma 35, a@ contains an 
INFORM—COMMIT for every ancestor least(a) up to Ica(Ieast(a),1”), which includes T, 
contradicting the well-formedness of a7. 


We are now able to show that the undo operator prescrves well-formedness. 


Lemma 40: If @ is a well-formed sequence of R(X)-opcrations, then undo(a) is a well-formed 
sequence of X-opcrations. 
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Proof: Vhe proof is by induction on the Icngth of a. ‘The basis is trivial. Assume a = a’a, 
where 7 is a single operation, and undo(a’) is a well-formed sequence of X-operations. Ifa is an 
INFORM-ABOR'T or INFORM —COMMIT, undo(a) is a prefix of undo(a@), by Lemma 36, and 
the result is immediate. 


ifaw is CREAVTECT), then undo(a) = undo(a’)z. By the well-formedness of a, CREATECT) 
docs not appear in a’, and so not in undo(a’). Hence, (i) is satisfied. ‘To sce (ii), assume that 
CREATEC(M) occurs in undof{a’) for access TT. Then Lemma 35 implies that 
INFORM ~—COMMIT—AT(X)OF(1") occurs afier CREATE’) in a. ‘Then well-formedness 
(the precondition for INFORM—COMMIT—AT(X)OFCE)) implics that a 
REQUEST—COMMITP for ‘I’ occurs in a’. and well-formedness also implics that the 
REQUEST ~ COMMIT for T° follows the CREATECF). ‘Therefore, the REQUEST— COMMIT 
occurs in undo(a’), and so'l” is not pending in undo(a’). ‘Thus, (ii) is satisfied. 


If w is a REQUEST—COMMIT for T, then again undo(a) = undo(a’)z, and by the well- 
formedness of a, (i) no REQUEST—COMMIT for ‘VF appears in a’, and so not in undo(a’), and 
(ii) Tis active after a’, and it follows that CREATE(I”) occurs in undo(a’). & 


4.3. Construction of a Resilient Object 


In this subsection, we describe a construction of a resilient object R(X) from a basic object X. 


Recall that a resilient object X is distinguished from a basic object in that it has INFORM —ABORT and 
INFORM—COMMIT opcrations, a different definition of well-formedness, and satisfies the resilicncy 
condition. ‘Ihe resilient object R(X) is constructed from the states, transition function and operation labels of 
the basic object X. The resilient object R(X) maintains a collection of "copies of X" (i.c. remembers states of 
X), one for cach active transaction, with a particular current copy (corresponding to the least active 
transaction) to which CREATE operations are sent. When R(X) receives an INFORM—ABORT, the 
appropriate stored copy becomes the current copy, thereby crasing the cffects of the opcrations in the scope of 
the INFORM — ABORT. 


‘The state of R(X) consists of a pair (act,map), where act is a sct of “active” transactions, and map is a 
function from act to states of basic object X. In the well-formed executions of R(X) (defined below), act will 
always be a subsct of the sct of ancestors of onc particular transaction in act, called Icast(act). (In case act has 
no least member (which, again, will not arise in executions with well-formed schedules), define least(act) 
arbitrarily.) The copy for Ieast(act) is considered to be current. The initial states of R(X) are those in which 
act = {To} and map(T)) is an initial state of the basic object X. In the following specification of the 
operations of R(X), Iet (act’smap’) be the state of R(X) prior to the operation, and (act,map) be the state of 
R(X) after the operation. 


e CREATE(T), T an access to X: 
Postcondition: ; 
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act = act’ U {T} 
map(U) = map(U) for all U € act - {7} 
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e@ INFORM —ABORT—AT(X)OFCT): 
Postcondition: 
act = act’ - {descendants(T)} 
map(U) = map’(U) for all U € act 


e INFORM —COMMIT—A'I(X)OF(1): 
Postcondition: 
if’! € act’ then 
begin 
act = (act’ - {T}) U {parent(T)} 
map(U) = map‘(U) for U € act - {parent(‘T)} 
map(parent(l)) = map’(T) 
end 
if I € act’ then act = act’ and map = map’ 


e REQUEST —COMMII(T\y): 
Precondition: 
Ieast(act’) = T 
(map'(T),REQUEST—COMMIT‘(T,v),s) is in the transition relation of X 
Postcondition: 
act = act’ 
map(U) = map’(U) for all U € act - {T} 
map(T) = s 


Now we prove that this implementation is a correct resilient object. 

Lemma 41: Let a be a well-formed schedule of R(X) which can leave R(X) in state (act,map). 
Then act coincides with the sct of transactions which are active after a. 

Proof: ‘The proof is by induction on the length of a. The basis is trivial. Let a = a'a, where 7 
is a single operation. ‘here are four cases, depending on the type of operation w. Each is 
immediate from the definition of active and the implementation of R(X). § 

Lemma 42: Let a be a well-formed schedule of R(X) which can leave R(X) in state (act,map). 
Then the following conditions hold. 


@ undo{a) is a schedule of basic object X which can leave X in state map(Icast(act)), and 


e if T is any transaction other than Ty. and alINFORM—ABORT—AT(X)OF(T)) is well- 
formed, then undo{aINFORM — ABOR'T— AT(X)OF(1")) is a schedule of basic object X 
which can leave X in state map(U), where U is the Icast clement of act which is not a 
descendant of T’. 


Proof: First. observe that if T is not an ancestor of Icast(act), and 
alINFORM —ABORT—AT(X)OF(I’) is well-formed, then Lemmas 41 and 39 imply that 
undo(alINFORM — ABORT—AT(X)OF(T’)) = undo(a), so the second condition follows from 
the first. 
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The proof is by induction on the length of a. In cach case, we prove the first condition, then the 
second condition assuming that I” is an ancestor of Ieast(act). By the observation above, this is 
sufficient. 


The basis is trivial. Let a = a’, where a is a single operation. [.ct (act’smap’) be a state of 
R(X) after a’, such that ((act’".map’),7.(act,mup)) is a transition for R(X). ‘Vhere are four cascs. 


1) a = CREATE) 
Then undo(a) = undo({a’)az. By the inductive assumption, undo(a’) is a schedule of X which can 
leave X in state map (Ieast(act’)). By the implementation of R(X), (map'(cast(act’)),,map(1)) is a 
transition of X, and ‘I = Ieast(act). Thus the first condition of the lemma is satisfied. 


To sec that the second condition holds, note that all active transactions after a are ancestors of T, 
and by well-formedness, are exactly the transactions active after a’, together with T. Let m be 
INFORM — ABORT — ATCX)JOFCE), where ‘I is an ancestor of T other than Vy and a@ is well- 
formed. If'l” is a proper descendant of least(act’), by |.emma 39, undo(ag) = undo(a’), which is 
a schedule of basic object X which can leave X in state map(Icast(act’))), by the inductive 
hypothesis. [fT is an ancestor of Ieast(act’), undo(ag) = undo(a’@), the least clement of act 
which is not a descendant of I” is also the least clement of act’ which is not a descendant of 1”, and 
the result follows by the inductive hypothesis. 


2) 7 = REQUEST—COMMIT(T,v) 
Then undo{a) = undo(a’)r. By the inductive assumption, undo{a’) is a schedule of X which can 
Icave X in state map'(Icast(act’)). By the implementation of R(X), (map (Icast(act’)),a7,map(T)) is a 
transition of X, and l = Ieast(act). ‘Vhus the first condition of the lemma is satisfied. 


‘fo see that the second condition holds, note that the active transactions after @ arc all ancestors 
of ‘IT. and by well-formedness, are exactly the transactions active after a’. Let gp be 
INFORM — ABORT—AT(X)JOF(T’), where ‘T” is an ancestor of ‘T other than Ty and ag is well- 
formed. Then undo(ag) = undo(a’p), which is a schedule of basic object X which can leave X in 
state map(Icast(act’))), by the inductive hypothesis. Furthermore, the least element of act which is 
not a descendant of 'I” is also the Icast element of act’ which is not a descendant of T’, and the 
result follows by the inductive hypothesis. 


3) 7 = INFORM—COMMIT— AT(X)OF(1) 
Then undo(a) = undo(a’). Also, map(Icast(act)) = map(least(act’)), by definition of R(X). The 
first condition follows. 


By the definition of R(X), Ieast(act) is an anccstor of Icast(act’). Ict @ be 
INFORM — ABORT— AT(X)OF(1"), where I” is an ancestor of least(act) other than Ty and ag is 
well-formed. Then a'p is well-formed, and undo(ag) = undo{a’p). Also, since a@ is well- 
formed, T’ # T. Let U and U’ be the Icast elements of act and act’, respectively, which are not 
descendants of T. 


if T € act’, or if U # parent(T), then U = U' and map(U) = map‘(U’), and the second 
condition follows from the inductive hypothesis. So assume that T € act’ and U = parent(T). 
Then since I” # ‘T) it follows that U' = ‘TP. Then map’(U’) = map(U), and the second condition 
again follows from the inductive hypothesis. 
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4) 7 = INFORM—ABORT—AT(X)OF(T) 
If Tis not an ancestor of least(act’), then undo(a@) = undo(a’), by Lemma 39. Furthermore, the 
state of R(X) is not changed. aINFORM—ABOR'T—AT(X)—OFCT) is well-formed only if 
oe INFORM— ABORT — AT(X)—OFCT) is, and the active transactions after a are exactly those 
active after a’. ‘Vhe result follows. 


Suppose that ‘I’ is an ancestor of least(act’). The first condition is immediate from the inductive 
hypothesis. Let m be INFORM — ABORT—ATCX)OFCI’), where Vis an ancestor of Ieast(act) 
other than us and ag is well-formed. Since act = act’ - descendants(‘l), Ieast(act), and hence T", 
is an ancestor of ‘1, undo(ag) = undo(a’mg) = undo(a’g), and the second condition follows as 
well. Of 

Theorem 43: R(X) is a resilient object. 


Proof: We must show that R(X) preserves well-formedness and satisfies the resiliency condition. 
That R(X) satisfies the resiliency condition follows immediately from Lemma 42. 


Assume that @ ts a well-formed schedule of R(X) and @ is an output operation of R(X) enabled 
afier an exccution with schedule a. We must show that aa is a well-formed sequence of R(X} 
operations. 


Since @ is an output, it has the form REQUEST—-COMMITI(T.v) for some access 'T and value v. 
Let (actsmap) be a state of R(X) after a, such that @ is enabled in (actmap). Clearly, a is an 
output of basic object X enabled from state map(Ieast(act)). By Iemma 42, undo(a) is a schedule 
of basic object X which can Icave X in state map(Icast(act))), so undo(a)r = undo(am) is a 
schedule of basic object X. 


Since X preserves well-formedness for basic objects, and by Lemma 40 undo({a) is a well-formed 
sequence of X-operations, undo(a) ends with the opcration p = CREATECT) and contains no 
other operations with transaction ‘I’. Let By be the prefix of « ending in m. Suppose first that a 
REQUEST—COMMIT for 'T occurs in a. Since a is well-formed, g is the only CREATE(T) 
operation in a, and by I.emma 34, the second REQUEST—CREATE for T follows g, and by the 
definition of undo, is in undo(a) if @ is, a contradiction. 


It remains to show that T is active after a. By Iemma 34, T is active after By. No 
INFORM—COMMIT for T can occur after @ in a. since by well-formedness, there is no 
REQUEST—COMMIT! for T in a. Also, since g is in undo(a), no INFORM—ABORT for an 
ancestor of T' can occur after p in a. ‘Thus T is still active after a. 


5. Concurrent Systems 

As with serial schedules in classical settings, our serial schedules contain no concurrency or resiliency and 
thus are too inefficient to use in practice. Their importance is solely for defining correctness for transaction 
systems. In this section, we define a new kind of system called a concurrent system. The new system consists 
of the same transactions as in a scrial system, a resilient object R(X) for every basic object X of the serial 


system, and a concurrent scheduler. 


Concurrent systems describe computations in which transactions run concurrently and can be aborted after 
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they have performed some work. ‘The concurrent scheduler has the joint responsibility of controlling 
concurrency and of scecing that the effects of aborted transactions (und their descendants) become undone. 
Concurrent systems make use of the roll-back capabilities of resilient objects to make sure that ABORT 
operations in concurrent systems have the same semantics (so far as the transactions can tell) as they do in 


scrial systems. 


Concurrent systems are defined in this section. In the next section, the more permissive “weak concurrent 
systems" are defined. In Section 7, we prove that the schedules of concurrent systems arc scrially correct, as a 


corollary of a weaker correctness property for the weak concurrent system. 


5.1. Lock Managers 

The scheduler we define is called the concurrent scheduler. \t is composed of several automata: a lock 
manager for every object X, and a single concurrent controller. ‘Vhe job of the lock managers is to insure that 
the associated object reecives no CREATES until the lock manager has received abort or commit information 
for all necessary preceding transactions. ‘This lock manager modcls an exclusive locking protocol derived 
from Moss’ algorithm [Mo]. ‘The lock manager has the following operations. 
Input Opcrations: 

INTERNAI—CREATE(T), where T is an access to X 


INFORM —COMMIT— A'E(X)OF(T), for’ any transaction 
INFORM — ABORT — AT(X)OF(T), for T any transaction 


Output Opcrations: 
CREATE(1), where T is an access to X 


‘The input operations INTERNAI.—~CREATE, INFORM—COMMIT and INFORM—ABORT will 
compose with corresponding output operations of the concurrent scheduler which we will construct in this 
subsection. The output CREATE operation composes with the CREA'TE input operation of the resilient 
object R(X). ‘The lock manager reccives and manages requests to access object X, using a hicrarchical locking 


scheme. It uses information about the commit and abort of transactions to decide when to release locks. 


Fach state s of the lock manager consists of the following three sets of transactions: lock —holders(s), 
create — requested(s), and created(s). Initially, lock—holders = {Tp}. and the other sets are empty. The 


opcrations work as follows. 


e INFERNAL—CREATET) 
Postcondition: 
create — requested(s) = create — requested(s’) U {T} 


e INFORM—COMMIT-— A'I(X)OF(T) 
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Postcondition: 
if Y € lock — holders(s’) then lock — holders(s) = (lock — holders(s’) - {1}) U {parent(T)} 


e@ INFORM — ABORT — A'TI(X)OF(CF) 
Postcondition: 
lock — holders(s) = lock — holders(s’) - descendants(T) 


e CREATE(T) 
Precondition: 
‘Tl’ € create — requested(s’) - created(s’) 
lock — holders(s') C ancestors(T) 
Postcondition: 
lock — holders(s) = lock — holders(s') U {T} 
created(s) = created(s’) U {1} 


Note that resilient object R(X) and the lock manager for X share the INFORM—ABORT and 
INFORM—COMMIT input operations. ‘These compose with the output from the concurrent controller 


defined below. 


lock — holders are ancestors of ‘I. When the lock manager learns about the commit of a transaction 'T for 
which it holds a lock, it releases the lock to 'I’s parent. When the lock manager Icarns about the abort of a 
transaction ‘T for which it holds a lock, it simply relcases all locks held by that transaction and its descendants. 


Our modcl provides an exceptionally simple and clear way of describing this important algorithm. 


A key property of lock managers is described by the following lemma. 

Lemma 44: ct X be an object and let ‘I’ and 'I” be accesses to X. Let U be an ancestor of T 
which is not an ancestor of I”. Let @ be a schedule of the lock manager for X. If CREATE(T) 
precedes CREATE(I") in a, then between the two CREATE operations, there is cither an 
INFORM—COMMIT—AT(X)OF(U) operation, or clse an INFORM—ABORT—AT(X) for 
some ancestor of T. 


lock—holders. Before the lock manager can send in CREATE(1"), it must be that all the 
transactions in lock—holders are ancestors of ‘I”. ‘There are only two ways in which this can 
happen. Once possibility is that the lock manager first receives INFORM—COMMITS for all 
ancestors of T up to Ica(I'!), including INFORM—COMMIT—AT(X)OF(U). The other 
possibility is that the lock manager first receives an INFORM — ABORT for an ancestor of T. 8 


5.2. The Concurrent Controller 
The concurrent controller is similar to the serial scheduler, but it allows siblings to proceed concurrently. In 
order to manage this properly, it interacts with “concurrent objects” (lock managers and resilicnt objects) 


instead of just basic objects. ‘The opcrations are as follows. 
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Input Operations: 
REQUESP-—CREATE(T) 
REQUEST-—COMMIT(Ey) 


Output Operations: 
CREATECT), ‘Pa non-access transaction 
INTERNAL.—CREATE(T), T an access transaction 
COMMITI(T,v) 
ABORTICT) 
INFORM —COMMIT—AT(X)OF(T) 
INFORM —ABORT— A'T(X)JOF(T) 


Each state s of the concurrent controller consists of five sects: create—requested(s), creatcd(s), 
commit— requested(s), committed(s), and aborted(s). The set commit—requested(s) is a sct of 
(transaction,valuc) pairs, and the others are sects of transactions. (As before, we will occasionally write T € 
commit — requested(s) for (Vv) € commit— requested(s) for some v.) All sets are initially empty except for 


create — requested, which is {To}. Define returned(s) = committed(s) U aborted(s). ‘The operations are as 


follows. 
@ REQUEST—CREATET) 
Postcondition: 


create — requested(s) = create — requested(s') U {1} 


e@ REQUEST —COMMII(T,v) 
Postcondition: 
commit — requested(s) = commit — requested(s’) U {(T,v)} 


e CREATE(T), T a non-access transaction 
Precondition: 
T € create — requested(s’) - created(s’) 
Postcondition: 
created(s) = created(s’) U {T} 


e INTERNAL—CREATE(T), T an access transaction 
Precondition: 
'T € create — requested(s’) - created(s’) 
Postcondition: 
created(s) = created(s’) U {T} 


e COMMIT(T,v) 
Precondition: 
(T,v) € commit — requested(s’) 
T € returned(s’) 
children(T) MN create — requested(s’) € returncd(s’) 
Postcondition: 
committed(s) = committed(s’) U {T} 


© ABORT(T) 
Precondition: 
'l € (create-requested(s’) - created(s')) U (commit— requested(s’) - returned(s’)) 
children(¥) N create — requested(s’) C returned(s’) 
Postcondition: 
created(s) = created(s’) U {TP} 
aborted(s) = aborted(s’) U {‘T} 


e INFORM —COMMIT—AT(X)OF(T): 
Precondition: 
‘ft € committed(s’) 


e INFORM — ABORT—AT(X)OF(T): 
Precondition: 
'T € aborted(s’) 


The concurrent controller is closcly related to the serial scheduler. In place of the scrial scheduler’s 
CREATE operations, the concurrent controller has two kinds of operations, CREATE operations and 
INTERNAL—CREATE operations. ‘The former is used for interaction with non-access transactions, while 
the latter is used for interaction with access transactions. From the concurrent controller's viewpoint, the two 
operations are the same; however, our naming convention for operations requires us to assign them different 
names, since the INITERNAL—CREATE operations are intended to be identified with 
INFERNAL—CREATE operations of the lock managers (which also have CREATE operations, for 
interaction with the resilient objects). ‘The precondition on the scrial scheduler’s CREATE opcration which 
insures scrial processing of sibling transactions, docs not appear in the concurrent controller. Thus, the 
concurrent controller may run any number of sibling transactions concurrently, provided their parent has 


requested their creation. 


The concurrent controller's COMMIT operation is the same as the serial schedulers COMMIT operation 
(except for a minor difference in bookkeeping). ‘The concurrent controller's ABORT operation is different, 
however; in addition to aborting a transaction in the way that the scrial scheduler docs, the. concurrent 
controller has the additional capability to abort a transaction that has actually been created and has carried out 
some steps. [In this particular formulation, aborts occur if the transaction was not created (as with the scrial 
scheduler), or if the transaction has previously requested to commit, and its children have returned. Together 
with the requirements on the COMMIT operation, this condition insures that all transaction completion 
occurs bottom-up. In the weak concurrent system to be considered in Section 6, a different, “weak”, 
concurrent controller will be used; it differs from the concurrent controller of this section precisely in not 


requiring ABORT opcrations to wait for their transactions (and subtransactions) to complete. 


The concurrent controller also has two additional operations not present in the serial scheduler. ‘These 
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operations allow the concurrent controller to forward necessary abort and commit information to the lock 


managers and resilient objects. 


Lemma 45: [.ct a be a schedule of the concurrent scheduler, and Ict s be a state which can result 
from applying @ to the initial state. ‘Then the following conditions are truc. 


1.T is in create — requested(s) exactly if 1 = Ny or a contains a REQUEST —CREATEC(T) 
operation, 


2. 1f ‘is a non-access transaction, then ‘Tl’ is in created(s) exactly if @ contains cither a 
CREATE(T) or ABORTCE) operation. 


3. 1f T is an access transaction, then ‘fT is in created(s) exactly if @ contains cither an 
INTERNAL —CREATE(T) or ABOR TCT) operation. 


4. (Iv) is in commit—requested(s) exactly if a contains a COMMIT—RFEQUEST(T,v) 
operation. 


5. (T,v) is in committed(s) exactly if a contains a COMMIT(S,v) operation. 


6. 'l is in aborted(s) exactly if a contains an ABOR'I(T) operation. 


5.3. Concurrent Systems 
‘The composition of transactions, resilient objects and the concurrent scheduler (lock managers and 
concurrent controller) is the concurrent system. A schedule of the concurrent system is a concurrent schedule, 


and the opcrations of a concurrent system are concurrent operations. 


A sequence @ of concurrent operations is well-formed if for every primitive P, a|P is well-formed (using the 


appropriate definition of well-formedness). 


‘The main result of this paper is that every concurrent schedule is scrially correct. ‘This will be proved as a 


corollary of a stronger result, in Section 7. 


5.4. Properties of Concurrent Systems 

As we did for serial schedules, we now prove some useful basic properties for concurrent schedules. ‘These 
lemmas describe the possible kinds and orders of operations that can occur in well-formed concurrent 
schedules. Later, we will sec that all concurrent schedules are well-formed, so these properties actually follow 
just from the fact that these schedules are concurrent. All results and proofs in this subsection are 
straightforward. 


Lemma 46: [ct a be a well-formed concurrent schedule, and Ict T # No be a transaction. 


L. If @ contains any operation with transaction ‘T, then a contains a CREATE(T) and a 
REQUEST —CREATECP). 
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2.1f a contains a COMMIT for ‘Ty then @ contains a REQUEST—COMMIT for T, a 
CREATECT) and a REQUEST—CREAPECT). 
3. Ifa contains an ABOR TCT), then a contains a REQUEST —CREATE(T). 
Lemma 47: L.ct a be a well-formed concurrent schedule, and ‘la transaction. Assume that some 
descendant of Tis in transaction(a). ‘Phen the following hold. 
1. CREATEC?) occurs in a. 
2. 1f T # Tp then REQUEST — CREATE) occurs in a. 
Lemma 48: [ct a be a well-formed concurrent schedule, and Iet ‘I # Ny be a transaction. 


1. 1f a contains a REQUEST—CREATE(T), but does not contain a return operation for T,- 
then parent(l) is live in a. 


2. If T is live in a, then parent('l’) is live in a. 


3.1f @ contains a REQUEST—CREATECE) but docs not contain a CREATE(T) or 
ABOR I(T), then parent(T) is live in a. 


Proof: 1. Well-formcdness implies that the REQUEST—CREATE(T) is preceded by a 
CREAT E(parent(l')). Suppose that parent(l) is not live in a. ‘Then a return operation for 
parent(T) occurs in a. In case the return operation for parent(l) is an ABORT(parent(T)), 
scheduler preconditions imply that the CREATK(parent(l)) must precede the 
ABORT(parent(l)). ‘Then the scheduler preconditions for the return operation imply that the 
return for parent(l) must be preceded by a REQUEST—COMMIT for parent(T). By well- 
formedness, the KEQUEST—COMMIT for parent) must follow the REQUEST —CREATKT), 
so that the return for parent(T) must follow the REQUEST—CREATEC(T) Then the scheduler 
preconditions for the return operation imply that there must be a return operation for T in a, a 
contradiction. 


2. and 3. are as in Lemma 17. § 
Lemma 49: [ct a be a well-formed concurrent schedule, and ict T be a transaction. 


1. If a contains a REQUEST—CREATE(1), but does not contain a return operation for T, 
then all proper ancestors of T arc live in a. 


2. If T is live in a, then any ancestor of T is live in a. 


3. If a contains a REQUEST—CREATE(T) but docs not contain a CREATE(T) or 
ABORT(T), then all proper ancestors of T are live in a. 


Lemma 50: Let a be a well-formed concurrent schedule, and Iet T and I” be transactions with T’ 
a descendant of T. Assume that there is a return opcration for T in a. 


1. If there is a REQUEST —CREATE(T") in a, then there is a return opcration for T’ in a. 


2. If T° is in transaction(a), then there is a return operation for T’ in a. 


Proof: 
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1. By Lemma 49. 


2. By ].emma 46 and part 1. 


Lemma 51: Let @ be a well-formed concurrent schedule. Ifa return operation for Tis in a, then 
it follows all operations in a whose transaction is ‘Il. - 


Proof: First consider the case where T is not an access. If no CREA TE(T) occurs in a, the result 
is immediate, so assume that CREA'TE(T) occurs in a. In case an ABORT(T) occurs in a, 
scheduler preconditions imply that the CREATE(!) must precede the ABOR'I(T). Then the 
return operation for ‘must be preceded by a REQUEST—COMMIT for ‘I. by scheduler 
preconditions. Well-formedness implies that the REQUEST—COMMIT is preceded by 
CREATE(T), and is not followed by any output opcrations of 'T. Phus, the only serial operations 
of 'T that could follow the REQUEST— COMMIT are return operations of children of T. 


Lect T° be a child of ‘1 for which a return operation occurs in a. By scheduler preconditions, 
there is only one return operation for TT in a. By Lemma 46, @ also contains 
REQUEST—CREATE(I’). Since this is an output operation of ‘T, it precedes the 
REQUEST—COMMIT for T, and hence preeedes the return operation for ‘T. Then the scheduler 
preconditions imply that the return operation for I” precedes the return for Tf. 


Next, consider the case where 'I is an access. If no INFERNAI.—CREATE(T) occurs in a, the 
result is immediate, so assume that INTERNAL—CREATE(T) occurs in a. In case an 
ABORT(?) occurs in a, scheduler preconditions imply that the INFERNAI.—CREATEC(T) must 
precede the ABORT(T). Then the return operation for ‘T must be preceded by a 
REQUEST—COMMITF for T. and well-formedness implics that this is in turn preceded by 
CREATECT). ‘Phus, no serial operations of T can follow the return operation for T. 

Lemma 52: L.ct a be a well-formed concurrent schedule. Ifa return opcration for T is in a, then 
it follows all operations in a whose transactions are descendants of T. 

Proof: Since a return operation for T occurs in a, we have 'T # T>- Let T’ be a descendant of T, 
and assume for the sake of obtaining a contradiction that a serial operation w with transaction(7) 
= T occurs after the return for Tin a. [ct a’ be the prefix of a preceding a. 


By Lemma 46, a’ contains a REQUEST—CREATE(T’). Then Lemma 50 implies that a must 
contain a return operation for I”. But then the well-formed schedule a’a contains a return 
operation for Tl” followed by an operation of IT’, which contradicts Lemma 51. # 


Weak concurrent systems are defined in the following section, and many of their propertics are stated and 
proved. Weak concurrent systems are obtained by replacing the concurrent scheduler with a more permissive 
scheduler, the weak concurrent scheduler. Results in Section 7 prove that every execution of the concurrent 
system is also an exccution of the weak concurrent system. ‘Thus, additional interesting properties of 
concurrent system behavior follow immediately from the corresponding propertics of weak concurrent system 


behavior, proven in that section. 
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6. Weak Concurrent Systems 

In this section, we define "weak concurrent systems”, which are exactly the same as concurrent systems, 
except that they have a more permissive controller, the “weak concurrent controller”. ‘The weak concurrent 
controller reports aborts to a transaction’s parent while there is still activity going on in the aborted 
transaction’s subtree. In this paper. weak concurrent systems are used primarily to provide an intermediate 
step in proving the correctness of concurrent systems: proving a weaker condition for weak concurrent 
systems allows us to infer the stronger correctness condition for concurrent systems. However, weak 
concurrent systems arc also of interest in themselves. In a distributed implementation of a nested transaction 
system, performance considerations may make it important for the system to allow a transaction to abort 
without waiting for activity in the transaction’s subtree to subside. In this case, a weak concurrent system 
might be an appropriate choice, even though the correctness conditions which they satisfy are weaker. Weak 
concurrent systems also appears to have further technical usc, for example in providing simple explanations of 


the ideas used in “orphan detection" algorithms [H1.M W]. 


6.1. The Weak Concurrent Controller 
In this subsection, we define the weak concurrent controller. As we have already said, it is identical to the 
concurrent controller except that it has a more permissive ABORT operation. For convenience, we describe 


the controller here in its entirety. It has the same operations as the concurrent controller: 


Input Operations: 
REQUEST —CREATE(T) 
REQUEST—COMMITCE,v) 

Output Operations: 
CREATECI), T a non-access transaction 
INTERNAL—CREATECT), T an access transaction 
COMMIT(f,v) 
ABORT(T) 
INFORM —COMMIT— AT(X)OF(E) 
INFORM — ABORT— AT(X)OF(L) 


Each state s of the concurrent controller consists of five sets: | crcate—requcstcd(s), created(s), 
commit—requested(s), committed(s), and aborted(s). The set commit—requestcd(s) is a set of 
(transaction,valuc) pairs, and the others are scts of transactions. (As before, we will occasionally write T € 
commit—requested(s) for (Iv) € commit—requested(s) for some v.) All are empty initially except for 
create — requested, which is {Tp}. Define returned(s) = committcd(s) U aborted(s). ‘The operations are as 
follows. 

e REQUEST—CREATE(T) 
Postcondition: , 
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create — requested(s) = create — requested(s’) U {1} 


e REQULEST—COMMITCI.) 
Postcondition: 
commit— requested(s) = commit—requested(s’) U {(Iv)} 


e CREATECT), Ta non-access transaction 
Precondition: 
Tl € create — requested(s’) - created(s’) 
Postcondition: 
created(s) = created(s’) U {T} 


e INTERNAI.—CREATECT), 'T an access transaction 
Precondition: 
‘Tl’ € create — requested(s’) - created(s’) 
Postcondition: 
created(s) = created(s’) U {1} 


e COMMI'I(T,v) 
Precondition: 
(Tv) € commit— requested(s’) 
'l € returned(s’) 
children(l') MN create — requested(s’) € returned(s’) 
Postcondition: 
committed(s) = committed(s’) U {T} 


e ABORT(T) 
Precondition: 
T € create-requested(s’) - returned(s’) 
Postcondition: 
created(s) = crcated(s’) U {T} 
abortcd(s) = aborted(s’) U {T} 


e INFORM —-COMMIT—AT(X)OF(T): 
Precondition: 
T € committed(s’) 


e INFORM — ABORT — AT(X)OF(T): 
Precondition: 
T € aborted(s’) 


Thus, the weak concurrent controller is permitted to abort any transaction that has had its creation 


requested, and which has not yet returned. 


Lemma 53: Let a be a schedule of the concurrent scheduler, and Ict s be a state which can result 
from applying a to the initial state. ‘hen the following conditions are true. 


1. T is in create —requested(s) exactly if T = T) or a contains a REQUEST—CREATE(T) 
operation. 
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2. 1f T is a non-access transaction, then ‘Tis in created(s) exactly if a contains cither a 
CREATE(T) or ABORT(T) operation. 


3. 1f ‘Tis an access transaction, then ‘I’ is in created(s) exactly if @ contains cither an 
INTERNAL —CREATECP) or ABOR'ECL) operation. 


4.(T.v) is in commit—requested(s) exactly if @ contains a COMMI'T—REQUEST(I.v) 
operation. 


5. (Vv) is in committed(s) exactly if a contains aCOMMI'T(I,v) operation. 


6. Tis in aborted(s) exactly if a contains an ABOR'T(T) operation. 


6.2. Weak Concurrent Systems 
The composition of transactions, resilient objects and the weak concurrent scheduler (lock managers and 
weak concurrent controller) is the weak concurrent system. A schedule of the weak concurrent system is a 


weak concurrent schedule. 


Weak concurrent systems cxhibit nice behavior to transactions except possibly to those which are 
descendants of aborted transactions. Thus, we say that a transaction T is an orphan in any sequence a of 
operations provided that an ancestor of ‘T is aborted in a. In many of the propertics we prove for weak 


concurrent systems, we will have to specify that the transactions involved are not orphans. 


6.3. Properties of Weak Concurrent Systems 
As we did for serial and concurrent schedules, we here prove a number of uscful basic properties for weak 


concurrent schedules. As before, most of these properties are simple to state and prove. 


6.3.1. Operations in Weak Concurrent Schedules 

As before, we include a collection of lemmas describing the possible kinds and orders of operations that can 
occur in well-formed weak concurrent schedules. ‘These lemmas are analogous to some in Scction 5, and have 
similar proofs; the main difference is that we must take proper care with orphans. As before, we go on to 
show that all weak concurrent schedulcs are well-formed, so these propertics actually follow just from the fact 
that these schedules are weak concurrent. 


Lemma 54: Let a be a well-formed weak concurrent schedule, and Ict T # To be a transaction. 


1. 1f a contains any operation with transaction T, then a contains a CREATE(T), and a 
REQUEST— CREATE(T). 


2. 1f a contains a COMMIT for T, then @ contains a REQUEST—COMMIT for T, a 
CREATE(L) and a REQUEST —CREATE(T). 


3. If a contains an ABORT(T), then @ contains a REQUEST—CREATE(1). 
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Lenima 55: L.ct a be a well-formed weak concurrent schedule, and ‘la transaction. Assume that 
some descendant of T is in transaction(a). ‘Then the following hold. 


1. CREATECT) occurs in a. . 
2.1F 1 # ly then REQUEST —CREATECT) occurs in @. 
Lemma 56: Let aw be a well-formed weak concurrent schedule, and Iet T # To 


lL. If @ contains a REQUEST —CREA'TECT), but does not contain a return operation for T, 
then parent(1) is not committed in a. 


2. If 'T is live in a, then parent(T) is not committed in a. 


3.1f a contains a REQUEST—CREATE(T) but docs not contain a CREATE(T) or 
ABOR TCP), then parent(‘l) is not committed in a. 


Proof: 1. Suppose a COMMIT opcration for parent(T) occurs in a. ‘Then the weak concurrent 
controller preconditions for the COMMIT operation imply that the COMMIT for parent(T) must 
be preceded by a REQUEST—COMMIT for parent). By well-formedness, the 
REQUEST—COMMIT for parent(T) must follow the REQUEST—CREATE(T), so that the 
COMMIT for parent(l) must follow the REQUEST—CREATECT). Then the weak concurrent 
controller preconditions for the COMMIT operation imply that there must be a COMMIT 
operation for lin a, a contradiction. 


2. and 3. are asin 3.6.2. Bf 
Lemma 57: Let a be a well-formed weak concurrent schedule, and Ict T be a transaction which 
is not an orphan in a. 


1. If a contains a REQUEST —CREATEC(T), but does not contain a COMMIT opcration for 
‘T, then all proper ancestors of T are live in a. 

2. If T is live in a, then all proper ancestors of T are live in a. 

3. If a contains a REQUEST—CREATE(T) but does not contain a CREATE(T), then all 
proper ancestors of T arc live in a. 


Proof: By repcated use of the previous lemma, well-formedness and the weak concurrent 
controller preconditions. # 


Lemma 58: Let a be a well-formed weak concurrent schedule, and Ict T and T be transactions 
with I” a descendant of T. Assume that I” is not an orphan in @ and that there is a COMMIT 
operation for T in a. 


1. If there is a REQUEST—CREATE(T’) in a, then there is a COMMIT operation for T in 
a. 


2. If T’ is in transaction(a), then there is a COMMIT operation for T’ in a. 
Proof: 


1. By Lemma 57. 


2. By L-cmma 54 and part 1. 


6.3.2. Objects and Locking 
In this paragraph, we give two simple lemmas about the behavior of the locking strategy. 

Lemma 59; I.ct @ be a weak concurrent schedule. [ct X be an object, and Ict ‘I’ and ‘I” be 
accesses to X. Let U be an ancestor of ‘which is not an ancestor of ‘I’. Assume that CREATE(L) 
precedes CREATEC(1’) in a. 

1.Vhere is cither an INFORM—COMMIT—AT(X)OF(U), or else — an 
INFORM — ABORT— AT(X) for some ancestor of Il, occurring between CREA'TE(T) and 
CREATECT’) in a. 

2. FKither CREATE(I’) is preceded by a COMMIT operation for U, and by a 
REQUEST—COMMIT opcration for U, or else CREATE(1") is preceded by an ABORT 
operation for some ancestor of T. 


Proof: 


1. By Lemma 44. 


2. By part 1 and the preconditions of the weak concurrent controller. 


Lemma 60: Let a be a well-formed weak concurrent schedule, and X a basic object. ‘Then the 
sct of active transactions after a|R(X) is exactly the sct of lockholders in the lock manager for X 
after a. 


Proof: By induction on the Iength of a. & 


6.3.3. Well-Formedness 
Here, we show that every weak concurrent schedule is well-formed. It follows that all the propertics proved 
earlicr in this scction are actually truc for all weak concurrent schedules. From now on, we will use these 


properties without explicitly mentioning well-formedness. 

Lemma 61: [ct a be a weak concurrent schedule. Then a is well-formed. 

Proof: By induction on the length of schedules. ‘lhe base, length = 0, is trivial. Suppose that 
am is a weak concurrent schedule, where zw is a single opcration, and assume that a@ is well- 
formed. If w is an output of a primitive P, then the result is immediate, since each primitive 
preserves well-formedness. No INTFERNAL—CREATE operation can cause a violation. So 
assume that a is an input to a primitive P. It suffices to show that aa|P is well-formed. There are 
SiX Cases, 


(1) w is CREATECT) and T is a non-access transaction. 
The controller preconditions insure that CREATE(T) does not appear in a. 


(2) @ is CREATE(T) and T is an access to resilient object R(X). 
By the lock manager preconditions, no CREATE(T) appears in a. The lock manager 
preconditions and |.cmma 60 imply that all the transactions which are active after a are ancestors 
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of T. 


(3) a is COMMITCE.y). 
Then a is an input to transaction parent(l). Weak concurrent controller preconditions imply that 
a contains REQUEST—COMMITI(I.v), and so Lemma 54 implies that @ contains 
REQUEST—CREATE(T). Also, weak concurrent controller preconditions insure that a docs not 
contain a return operation for T. 


(4) a is ABOR'I(T). 
‘Then a is an input to transaction parent(l). Weak concurrent controller preconditions imply that 
a@ contains a REQUEST—CREA'TECT). Weak concurrent controller preconditions insure that a 
docs not contain a return operation for T. 


(5) 7 is INFORM—COMMIT— A'E(X)OF(1) at resilient object R(X). 
By the preconditions of the weak controller, a@ contains a COMMIT for ‘Tl. If 
INFORM—ABORT—AT(X)OF(T) occurs in a, then @ also contains an ABORT for T, which 
contradicts weak concurrent controller preconditions. Thus, no 
INFORM — ABOR'F—AT(X)OF(T) occurs in a. Since a COMMIT for T occurs in a, weak 
concurrent controller preconditions imply that a REQUEST— COMMIT for’ also occurs in a. 


(6) @ is INFORM — ABORT —AT(X)OF(T) at resilient object R(X). 
By the preconditions of the weak concurrent controller, a contains ABORT(T). — If 
INFORM —COMMIT—A'I(X)OF(T) occurs in a, then @ contains a COMMIT for ‘T, which 
contradicts weak concurrent controller preconditions. Thus, no 
INFORM —COMMIT—AT(X)OF(T) occurs in a. Ef 


6.3.4. Visibility and Weak Concurrent Schedules 

‘This paragraph states and proves important propertics involving visibility in weak concurrent schedules. In 
particular, the most important result of this paragraph is Lemma 66, which relates the portion of a weak 
concurrent schedule which is visible to a particular transaction, to schedules of transactions and basic objects. 
The first lemma shows how visibility propagates among the transactions during a weak concurrent exccution. 


Lemma 62: ct aw be a weak concurrent schedule, where a is a single operation. 


1. If # is CREATE(1P), then visible(aa.T) = visible(a,parent(T))2. 
2. If 7 is COMMITI(T.\v), then visible(a7,parent(T)) = visible(a,T)a. 
3. If 7 is ABORT(1), then visible(aa,parent(T)) = visibie(a,parent(T))¢. 


4. If a is COMMIT(T,v), and IT” is a descendant of parent(T) but not T, then visible(aw,T’) - 
visible(aa,parent(l)) = visible(a.1°) - visible(a,T). 


Proof: 1. By Lemma 55, 7 is the first scrial operation in aw whose transaction is a descendant of 
T, and T is not visible to parent(T). ‘Thus any transaction other than T visible to T in a7 is visible 
to parent((T) in aw. Then parent(l) is visible to T in aw, and by Lemma 8, 
visible(aa.parent(l))a = visible(az,T). 


, 


46 


By the definition of visibility, any transaction visible to parent(T) in ag is visible to parent(T’) in 
a, and visible(a.parent(l)) = visible(aa.parent(l)). Substituting in the equality above, we have 
the result. 


2. By the definition of visibility, any transaction visible to parent(‘l) in aa is cither visible to 
parent(T) in a, or is visible to Tin a. But any transaction visible to parent(l) in @ is visible to T in 
@, so we have that any transaction visible to parent(l) in aq is visible to T in a, and 
visible(aa.parent(l)) is a subsequence of visible(a, Va. lt follows immediately from the 
definition of visibility that any transaction visible to ‘Tin @ is visible to parcnt(l’) in a, so that 
visible(a, P) is a subsequence of visible(am.parent(l'). ‘Ihe result is immediate. 


3. Immediate from the definition of visibility. 


4. Clearly, visible(a, I") is a subsequence of visible(aq1").. Any operation in visible(aa,T’) - 
visible(a, 1”) has a transaction which is a descendant of I’, and so is cither 7 or is visible to T in a, 
and thus is in visible(a,T)a. ‘Thus we have visible(aq,!") - visible(a.l')a = visible(a,I”) - 
visible(a.V)a. As m is not in visible(a,1”), this cquals visible(a.1") - visible(a.l). By part 2, 
visible(aa,parent(l)) = visible(a,!)a, and the result follows by substitution in the first identity. 
| 


Now we prove two lemmas involving visibility and the behavior of resilicnt objects in weak concurrent 


systems. 

Lemma 63: |.ct a be a weak concurrent schedule. Let R(X) be a resilicnt object, and Iet ‘T and T 
be accesses to R(X). If’ is live and not an orphan in a and CREATE(T) occurs in a, then cither 
Tis visible to IT in a, or clse CREATE(I) is in the scope of an 
INFORM — ABORT — AT(X)OF(U) in afR(X). 


Proof: There are two cascs. 


(1) CREATECT) precedes CREATE(T’) in a. 
Assume T is not visible to T in a. Then Iemma 59 implics that there is an 
INFORM — ABORT — AT(X) operation for some ancestor of ‘I, occurring after CREATE(1) in a. 


(2) CREATE(T’) precedes CREATE(T) in a 
‘Then 1.emma 59 implics that there is cither a COMMIT or an ABORT for some ancestor of T’, in 
a. Since T° is not an orphan in a, there isa COMMIT for an ancestor of I” in a. Then I.cmma 58 
implies that 1” is returned in a, acontradiction. § 

Lemma 64: Let a be a weak concurrent schedule. Let R(X) be a resilient object, let T and T° be 
accesses to R(X), and Ict 1” be any transaction. Assume that ‘l” is not an orphan in a. If an 
operation a of T precedes an operation vw of T in a, @ is not in the scope of an 
INFORM—ABORT and T’ is visible to T” in a, then 'T is visible to T” in a. 

Proof: By well-formedness, CREATE(1) and CREATE(T’) are operations in a, in that order. 
let a’ be the prefix of a ending with CREATE(1’). ‘Then T is live and not an orphan in a’. By 
Lemma 63, T is visible to 'T” in a’, and so in a. Lemma 8 implics that 'T is visible to T” in a. Ef 


The following lemma is straightforward. 
Lemma 65: Lct a be a weak concurrent schedule, and Ict ‘I be a transaction which is not an 


47 


orphan in a. Any transaction I” visible to ‘Tin @ is not an orphan in @. 


Proof: If I” is an ancestor of I’, the result is immediate. Otherwise, COMMIT opcrations appear 
in a@ for every proper descendant of lea(1 J") that is an ancestor of I". By well-formedness, none 
of these transactions has aborted. Since the remaining ancestors of I” are also ancestors of T, and 
the result follows. # 


We are now ready to prove the key Iemma of this paragraph. 


Lemma 66: [ct a be a weak concurrent schedule, let ‘1 be live and not an orphan in a, and Iet P 
be a resilicnt primitive. 


epee 


2. 1f P is a resilient object R(X), then visible(a,1)|R(X) is a prefix of undo(a|R(X)) and a: 
schedule of basic object X. 


Proof: 1. Immediate from |.cmmuas 11 and 1. 


2. First, we show that any opcration in visible(a,1){R(X) also occurs in undo(ajR(X)). If is in 
visible(a, T)|R(X), it means that all ancestors of transaction(a) up to Ica(transaction(a),T) have 
committed. By assumption, Tis not an orphan in a, so Lemma 65 implies that transaction(s) is 
not an orphan in a. ‘Thus, by the preconditions of the weak concurrent controller there is no 
INFORM — ABORT for any ancestor of transaction(2) in a. ‘Therefore, a is in undo(a|R(X)). 


Now we consider any two operations @ and a of undo(ajR(X)), where a precedes a’. Assume 
that w’ is in visible(a,1)[ R(X). Let TI" = transaction(a) and I” = transaction(a’). Then T is 
visible to I’ in a, and I” is not an orphan in @ by Lemma 65. Since a is in undo(a[R(X)), no 
INFORM — ABORT occurs at R(X) for any ancestor of I” in a, with a in its scope. Then Lemma 
64 implics that I” is visible to ‘Tin a. ‘Thus, v7 is in visible(a,l){R(X). It follows that 
visible(a,T)|R(X) is a prefix of undo(alR(X)). 


By Lemma 61, a]R(X) is a well-formed schedule of resilient object R(X). Then the resiliency 
condition implics that undo(a[R(X)) is a schedule of basic object X. So by Lemma 1, 
visible(a, T)|R(X) is a schedule of basic object X. 


Finally, we prove that, in a weak concurrent schedule, concurrently exccuting transactions access disjoint 


sets of resilient objects. 

Lemma 67: Let a be a weak concurrent schedule, with transactions T and T live and not 
orphans in a. Let I = Iea(T,1"). Let B = visible(a,1) - visible(a,I”) and B’ = visible(a,T’) - 
visible(a,T”). ‘Then no resilient object has opcrations in both B and B’. 

Proof: The result is trivial if ‘I’ is an ancestor of I” or vice versa. So assume that Ica(T,T’) is 
neither 'T nor TI”. Let R(X) be a resilient object such that both B and f’ contain operations of 
R(X). By well-formedness, we can assume without loss of generality that there are two accesscs to 
X (not necessarily distinct) such that 7 = CREA'TE(U) and p = CREATE(V) arc in B and B’, 
respectively, and neither U nor V is visible to Ica(T,) in a. Also, we can assume that w appears 
in a no later than g. 


We have that U is visible to some ancestor of T in a, and V is visible to some ancestor of T’ in a, 
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and since ‘f and ‘I are not orphans in a, |.emma 65 implies that no ancestor of U or V has aborted 
in a. Also. neither U nor V is visible to lea(IJ1) in a, so it must be that U # V. But then a 
precedes in a. and |.emma 59 implics that some ancestor of Tis committed in a. ‘Then Lemma 
57 implics that Tis returned in a, a contradiction. Bt 


7. Simulation of Serial Systems by Concurrent Systems 

In this section, we prove the main results of this paper, that concurrent schedules are serially correct, and 
that weak concurrent schedules are correct at Ty Both these results follow from an interesting theorem about 
weak concurrent schedules, which says that the portion of any weak concurrent schedule which is visible to a 


live non-orphan transaction is equivalent to (i.c. looks the same at a// primitives as) a scrial schedule. 


The proof of this theorem is quite interesting, as it provides considerable insight into the scheduling 
algorithm, ‘The proof shows not only that a transaction’s view of a weak concurrent schedule is equivalent to 
some scrial schedule, but by a recursive construction, it actually produces such a schedule. It is interesting and 
instructive to observe how the views that different transactions have of the system exccution get passed up 


and down the transaction tree, as CREATES, COMMITS and ABORTS occur. 
Theorem 68: |.ct a be a weak concurrent schedule, and ‘Tl any transaction which is live and not 
an orphan in a. ‘When there is a scrial schedule B which is equivalent to visible(a@,T). 
Proof: We proceed by induction on the Iength of a. ‘The basis, length 0, is trivial. Fix @ of 
length at Icast 1, and assume that the claim is true for all shorter weak concurrent schedules. Let a 
be the last operation of a, and Iet a = a'a. Fix ‘T which is live and not an orphan in a. We must 
show that there is a scrial schedule B which is equivalent to visible(a,T). 


If w is not a scrial operation, then visible(a’/l') = visible(scrial(a’),T) = visible(scrial(a),T) = 
visible(a, 1), and the result is immediate by induction. So we can assume that is a scrial 
operation. Also, if transaction(7) is not visible to ‘Tin a, then visible(a,T) = visible(a’,T), and 
the result is again immediate by induction. ‘Thus, we can assume that transaction(7) is visible to 'T 
in a. Also, T is not an orphan in a’. 


There are four cases. 


(1) w is an output operation of a transaction or resilient object. 
Then the inductive hypothesis implies the existence of a scrial schedule B’ which is equivalent to 
visible(a’, 1). Let 8B = B’m. We must show that B is equivalent to visible(a,'F) and scrial. 


Let P be any primitive. Then B|P = B'x|P = visible(a’,T)a|P by inductive hypothesis, = 
visible(a,T)[P, by Lemma 12. Therefore, B is equivalent to visible(a,T). 


Let w be an output of primitive P. Then B|P = visibic(a,1)|P by equivalence, which is a 
schedule of P by Lemma 66. Lemma 4 implics that £ is serial. 


(2) @ isa CREATE(T’) operation. 
Then transaction(2) = 'I°, and so 'T" is visible to ‘Tin a. Then ].cmma 55 implics that a is the first 
operation whose transaction is a descendant of ‘T”. ‘Then by the definition of visibility, it must be 
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that ‘I” = T. By Lemma 57, parent(T) is live in a’. Since parent(l) is not an orphan, the inductive 
hypothesis implics the existence of a serial schedule B° which is equivalent to visible(a’,parent(T)). 
Let B = Ba. We must show that B is equivalent to visible(a@, 1) and serial. 


Let P be any primitive. ‘Phen B|P = B'a|P, = visible(a’parent(1))a|P by inductive hypothesis, 
= visible(a.!)|P. by Lemma 62. ‘Thus, £ is equivalent to visible(a,l). 


Consider any execution of the serial system having 8’ as its operation sequence, and Iet s* be the 
state of the serial scheduler after 8’. We show that 7 is enabled ins’, ‘That is, we show that IT € 
create — requested(s’), that ‘1 € created(s’), and that siblings( 1) M created(s’) C returned(s’). 


Consider any execution of the weak concurrent system having a as its operation sequence, and 
Ict s be the state of the weak concurrent scheduler after a’. State s contains a componcnt S. for the 
weak concurrent controller and a component Sy for the lock manager for cach object X. 


ff T = IT, then T € create—requested(s’) by the initial conditions. If T # Ty. then T € 
create—requested(s) by the preconditions of the concurrent scheduler, so a 
REQUEST— CREATE(T) operation occurs in a’. ‘The REQUEST— CREATECT) operation has 
transaction parent(l’), and so is in visible(a’,parcnt('l)), and thus is in 8’. Therefore, ‘T € 
create — requested(s’). 


if F € created(s’), then there is cither a CREATE(T) or an ABOR'TCT) operation in B’, and 
hence in a’. In the former casc, a would have two such operations, while in the latter case, a 
would have an ABOR'I(1) followed by a CREATE(1). Both are impossible, so ‘I € created(s’). 


Assume U € siblings(l) M created(s’). ‘Then there is either a CREATE(U) or an ABORT(U) 
operation in 8’. In the latter case, U is obviously in returned(s’). So suppose CREATE{U) occurs 
in B’, and so in visible(a’,parent('!')). Since CREATE(U) occurs at U, U is visibic to parent(T) = 
parent(U) in @’; thus, COMMIT(U.u) occurs in a’, for some u. Since COMMIT(U,u) occurs at 
parent(T), COMMIT(U,u) is in visible(a’parent(l)), and so in 8’. Thus, U € returned(s’). 


(3) 7 isa COMMIT(T’,v) operation. 

Then 1” = parent(”) = transaction(2) is visible to ‘T and not an orphan in a. Also, T" is not an 
orphan in a’, by Lemma 65. Then since a is well-formed, I” is live in a’, and so by Lemma 57, T” 
is live in a and so in a. Since T” is live and visible to ‘I, ‘I’ is an ancestor of T. Since T is live in 
a, Lemma 58 implies that T is not a descendant of ‘I. ‘he inductive hypothesis yields two serial 
schedules, 8’ and B”, which are equivalent to visible(a’,1”) and visible(a’.T), respectively. Let y 
= visible(B’\I"). Let B, = B’ - y and B, = B”-y. We show that B = yf, 78, is cquivalent to 
visible(a,T) and serial. 


Lemma 28 implics that y is a serial schedule. 

Since T” is visible to T’ in a’, Lemma 10 implies that visible(a’,T”’) = visible(visible(a’,1”),T”’), 
which is cquivalent to visible(B’1") = -y; thus y is cquivalent to visible(a’,I"’). Also, since T” is 
visible to I in a’, Lemma 10 implies that visible(a’\I"') = visible(visible(a’,T),1”’), which is 


equivalent to visible(B",1"). Thus, y is also equivalent to visible(B”, 1"). 


Then by I.cmma 31 (applied with scrial(a’) as the schedule a hypothesized in the Iemma), yB, 
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and yB, arc scrial schedules which are equivalent to B° and B”, respectively. 


We have that visible(a,1") = visible(a’t")a by Lemma 62, which is equivalent to B’m, which is 
in turn equivalent to yB, 7. ‘That is, visible(a,1™) is equivalent to yp 7. 


Since B” is equivalent to visible(a’.!') and y is equivalent to visible(a’/1"’). by Lemma 10, B,= 
B° - y is cquivalent to visible(a’, 1) - visible(a’ 1), = visible(a.l) - visible(a 1") by Lemma 62. 


‘Thus, B is equivalent to visible(a. TX visible(a.l)-(visible(a,1")). Since 1” is visible to Tin a, 
by E.emma 8, it is casy to sce that the same operations appear in this schedule as in visible(a,!). 
Let P be any primitive. ‘Vhen visible(a,I))|P is a prefix of visible(a.!){P, by Lemma 66. It 
follows that B|P = visible(a.)[P, so that B is equivalent to visible(a,1'). 


It remains to show that B is scrial. ‘This follows from Lemma 32, provided we can show that: 
(3.a) yB , 7 is a serial schedule, 
(3.b) I” sees everything in yB). 
(3.c) I’ sces everything in yB,. 
(3.d) y = visible(yB 1") = visible(yB,.1) and 
(3.c) no basic object has operations in both B , and B,. 


(3.a) Consider any execution of the serial system having YB , as its operation sequence, and Iet s 
be a state of the serial scheduler after yB }. We show that a is cnabied in state s’. ‘Than is, we show 
that (Iv) € commit—requested(s’), that I” € returned(s’), and that children(I”) A 
create — requcsted(s’) C returned(s’). 


Consider any exccution of the weak concurrent system having @ as its operation sequence, and 
let s be the state of the weak concurrent scheduler after a’, with components s, (the weak 
controller state), and Sy for every object X (the lock managers). 


Since the weak concurrent scheduler is able to perform COMMIT(T",v) in state s, it must be that 
(Vv) is in commit— requested(s_), and so it must be that ‘I” issucs a R EQUEST—COMMIT(T?’,v) 
in a. Since T° is visible to itsclf, and B° is cquivalent to visible(a’,1"), it follows that this 
REQUEST—COMMIT(T’,v) operation also occurs in YB}. Therefore, (Tv) is in 
commit — requested(s’). 


Since a@ is well-formed, at most one return operation for T appcars in a; thus, ‘T” is not in 
returned(s’). 


Fix U € children(T) M create — requested(s’). Then REQUEST —CREATE(V) is performed at 
T” in yB,, and hence in a’, so U € create ~ requested(s_). Since the weak concurrent scheduler is 
able to perform COMMIT(T’,v) in state s, it must be that U € returned(s_). Therefore, a return 
operation for U is performed at T, in a’. Since T° is visible to itsclf, and YB, is equivalent to 
visible{a’,1"), this implies that the return for U also occurs at T in YB,- Therefore, U is in 
returned(s’). 


(3.b) Immediate from Lemma 10. 


(3.c) Immediate from Lemma 10. 
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(3.d) We have that y is equivalent to both visible(BV1") and visible(B°, FP"), and that YB, and 
yB, are cquivalent to B° and B", respectively. By Lemma 10, y is equivalent to both 
visible(yB ,.1") and visible(yB,.1"). Equality follows. 


(3.c) Immediate from ].emma 67. 


(4) 2 is an ABORT(I") operation. 
Then ‘IT = parent(l”) = transaction(q) is visible to T in a, and so is not an orphan in a, by 
Lemma 65. ‘Then ‘Tl’ is live in a’, and by I.cemma 57, ‘[” is live in a’ and so in a. Since ‘I” is live 
and visible to lin a@, 'T is a descendant of I. Since ‘I is not an orphan in a, ‘lV is not a descendant 
of ‘I. ‘Whe inductive hypothesis yields two serial schedules, B’ and 8", which are cquivalent to 
visible(a’I"") and visible(a’,I’), respectively. Let 8, = B” - B’. We show that B = Ba, is 
equivalent to visible(a,l') and serial. 


By Lemma 31, B°B, is a serial schedule which is cquivalent to B”. 


I.ct P be a primitive other than I”. Then B|P = B'B,|\P = B"|P = visible(a’1)[P, = 
visible(a,F)}P by Lemma 62. Also, since TI” is visible to ‘Tin a, visible(a,!)[T” = 
visible(a, I" ){1", = visible(a’{V")af 1" by Lemma 62, = B’afI” = BII". Thus B is equivalent to 
visible(a,1'). 


It remains to show that is serial. ‘This follows from I|.emma 33, provided we can show that: 
(4.a) B’a is ascrial schedule, 
(4.b) T sces everything in BB. and 
(4.c) 8° = visible(B°I") = visible(B'B 1”). 


(4.a) Consider any execution of the scrial system having B’ as its operation sequence, and let s" 
be a state of the scrial scheduler after B’. We show that 7 is cnabled in state s’. That is, we show 
that I” € crcate—requested(s’), that T° € created(s’), and that siblings(T™) M created(s’) C 
returned(s’). 


Consider any execution of the weak concurrent system having a as its operation sequence, and 
Iet s be the state of the weak concurrent scheduler after a’, with components S, (the weak 
controller state), and S, for every object X (the lock managers). 


Since the weak concurrent scheduler is able to perform ABORT(T’) in state s, it must be that T 
is in create—requested(s ), and so it must be that ‘I” issucs a REQUEST—CREATE(1T’) in a’. 
Since ‘I” is visible to itself, and B° is cquivalent to visible(a’,I”), it follows that this 
REQUEST —CREATE(T’) operation also occurs in 8B’. Thercfore, T’ is in create — requested(s’). 


Since a cannot contain two ABORT(1’) operations, there cannot be an ABORT(T’) operation in 
a’, and so there cannot be one in 8’. Assume that there is a CREATE(T") in 8’. Then T is visible 
tol” in a’, so COMMIT (1’) occurs in a’. But then a COMMIT(T’) and and ABORT(T’) both 
occur in a, which cannot occur. Therefore, there is neither an ABORT(T’) nor a CREATECT) in 
B’, and so I” is not in created(s’). 


Fix U € siblings(1l’) A created(s’). Then there is a CREATE(U) in B*. But then U is visible to 
T” in a’, so that a COMMIT for U occurs in a’, and hence (because parent(U) is visible to T” in 
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a’)a COMMIT for U occurs in B’. ‘Therefore, U € returned(s’). 
(4.b) Immediate from |.cmma 10. 


(4.c) ‘The first equality follows from Lemma 10. Clearly, B° = visible(B’I"’) is a prefix of 
visible(B'B 1"). Equality follows because any operation in B, visible tol in BB, would also be 
visible to I” in a’, and so would be in B’ and not B,. ff 

Corollary 69: Every weak concurrent schedule is serially correct for every non-orphan non- 
access transaction. 

Proof: |.ct a be a weak concurrent schedule. [ct ‘I be a non-access transaction that is not an 
orphan in a. We must show that all is a serial schedule. Note that ‘T is not an orphan in any 
prefix of a. 


There are three cases: 


(1) afl is empty. 
Then the result is trivial. 


(2)'T is live in a. 
Then ‘Theorem 68 yields a serial schedule B that is cquivalent to visible(a,T). Thus, a[T = 
visible(a, F)[T = BYT, which suffices. 


(3) T is a transaction which is live in some proper prefix of a. 
Since @ is well-formed, a has a prefix a’, where w is a COMMIT operation for T, a [T = afl 
and T is live in @. ‘Then ‘Theorem 68 yields a scrial schedule B that is cquivalent to 
visible(a’ TP. ‘Thus, afl = a’ [PF = visible(a’JT)[l = BV, which suffices. # 


cy 


Now, since 'T, cannot become an orphan (having no ancestors to abort), our first major correctness result is 


immediate. 
Corollary 70: Every weak concurrent schedule is serially correct for Tp. 


Having proved correctness properties for weak concurrent schedules, we are now ready to prove the 


cofrectness of concurrent schedules. 

Lemma 71: Every concurrent execution is a weak concurrent execution. 

Proof: ‘The proof is by induction on exccution length, with a trivial basis. Let a = a’\s’,7,s be a 
concurrent execution with (s',7,s) a single step of the concurrent system, and assume the lemma 
holds for a’. Lets’ . and S. denote the states of the concurrent controller in system states s’ and s. 
If w is any operation other than an ABORT, the result is immediate, since the pre- and 
postconditions for all other operations are identical in the concurrent and weak concurrent 
systems. Assume that w is an ABOR'I(T). We must show that T € create-requested(s’,) - 
returncd(s’ o: 


Since w is enabled in state S, in the concurrent controller, T € (create-requested(s’.) - 
created(s’ ~) U (commit-requested(s’.) - returned(s’)). If T is in create-requested(s',) - 
created(s’), l.cmma 45 implics that a’ contains no CREATE) or ABORT(T) operation. By 
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well-formedness, a? also contains no COMMIT operation for Ty and the result follows from 
lemma 45. On the other hand, if Tis in commit-requesicd(s.) - returned(s’), Lemma 45 implies 
that a REQUEST —COMMIE operation for 'T occurs in a’. By well-formedness, this is preceded 
by a CREATECT) operation, and by the concurrent controller precondition, this is preceded by a 
REQUEST —CREA'TE for'l. Finally, again by t.cmmia 45, the result follows, ff 


Now we can prove the second major result of the paper. 
Corollary 72: Every concurrent schedule is serially correct. 


Proof: L.ct a be a concurrent schedule. ‘Then @ is also a weak concurrent schedule, by L.emma 
71, and is well-formed, by Lemma 61. We must show that @ is scrially correct for every 
transaction I’. ‘Where are three cases: 


(1) afT is empty. 
‘Then the result is trivial. 

(2)'l is live in a. 
By Lemma SO, all of T's ancestors are live in a, so that ‘Tis not an orphan in a. Then Corollary 69 
yiclds the result. 


(3) T is a transaction which is live in some proper prefix of a. 
By Lemma 5], @ has a prefix a’, where a is a return operation for T, a’ [PF = afl and T is live in 
a’. By Lemma 50, all of 1s ancestors are five in a’, so 'T is is not an orphan in a’. Then Corollary 
69 implics that a’ is scrially correct for I, so that a@ is serially correct for 'T. § 


For completeness, we include an analog of Theorem 68 for concurrent schedules. 
Theorem 73: Let a be a concurrent schedule, and T any transaction which is live in a. Then 
there is a scrial schedule B which is equivalent to visible(a,T). 
Proof: .emma 71 implics that @ is a weak concurrent schedule. Since T is live in a, Lemma 50 
implics that T is not an orphan in @. ‘Then ‘Theorem 68 yiclds the result. § 


8. Discussion 
In this paper, we have presented a formal modcl for describing nested transaction systems and their 
properties. The model has many features that we believe make it a major contribution to the understanding 


of transaction systems, and we highlight some of these below. 


First, the entire model is based on a very gencral and very simple underlying model for concurrent 
computation, the I/O automaton model. The gencral definitions and properties of this underlying model 
provide the necessary underpinnings for our entire transaction modelling cffort. ‘This modelling is very casy 
to learn and usc, and its uscfulncss extends much beyond transaction systems. Thus, it secms to us to be a 


very satisfactory foundation for our work. 


Our transaction system model permits simple, yet completely rigorous description of concurrency control 
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algorithms in ways which correspond very closcly to the usual informal ways of understanding the algorithms. 
‘Phe important components of transaction systems, the transactions, duta and schedulers, are described 


explicitly, which greatly facilitates reasoning about them. 


‘There is a substantial amount of work in this area which docs not represent all of these components 
explicitly, but only implicitly, by properties of their behavior [l-y,BBG,Go, for example]. ‘There are problems 
with this approach. A key ingredicnt that is usually absent from such implicit models is a clear notion of 
“causality”, describing how particular actions (operations) are triggered by other actions or states. [n contrast, 
our explicit representation of all system components as [/O automata makes it casy to understand cxactly 
what causes all operations to occur. When causality is important in reasoning about algorithms, as in [Go], 
implicit modcls can be extraordinarily difficult to usc. Even in cases where implicit models can be used, we 


sec the present work as providing a formal and intuitive basis for that work. 


Our model represents transactions as essentially arbitrary automata, subject only to simple syntactic 
constraints. ‘This approach is much more gencral than representing them as programs in some particular, 


overly-constrained language. 


The I/O automata mode! permits description of algorithms in an abstract form which is not ticd to a 
particular programming language or system, and which allows maximum nondeterminism. An 
impicmentation of an algorithm for a particular system will gencrally restrict the nondctcrminism allowed in 
our presentation, because of the need to tailor the implementation to the requirements of a particular 
environment. However, since the implementation is just a restriction of the abstract algorithm, correctness 


properties of the algorithm within our model will hold @ fortiori for the implementation. 


Formulating nested transaction systems as I/O automata permits precise formulation of the correctness 
conditions to be satisfied by concurrency control algorithms; those correctness conditions can be stated at the 
transaction interface, an interface which docs not contain explicit information about object representation. 
Because of this choice of interface, the correctness conditions can be stated in a robust way: the same 
conditions can be uscful for describing the propertics of many different kinds of algorithms, some of which 
manipulate the data in very different ways. Also, the correctness conditions can be described in a way that is 


meaningful to a uscr of the system. 


The particular correctness conditions that we describe in this paper involve scrial correctness at transaction 
interfaces. We belicve that these particular correctness definitions are very interesting, and will be useful for 
describing the correctness of most of the usual algorithms studied in the concurrency control area. That is, the 


same conditions appear to be the right ones to use to describe correctness of many different kinds of 
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algorithms, including those that usc locking, timestamps, multiple versions, and replicated data. 


‘The model permits rigorous correctness proofs to be carried out for concurrency control algorithms in ways 
that follow intuitive understanding of the algorithms. For example, in this paper, we have used the model to 
describe and show the correctness of a very important nested transaction concurrency control algorithm, Our 
correctness proofs are constructive and provide considerable intuition about the workings of the algorithm. 
In contrast to most correctness proofs for concurrent algorithms, our proofs arc not voluminous low-level 
casc-analyses; rather, they consist of a large number of clear and natural lemmas about the behavior of the 
algorithm. ‘hese lemmas can be understood individually, and build upon cach other in the manner of good 


mathematics. Many of the lemmas should be reusable in extensions of this work as well. 


A successful model of nested transactions should contain the classical theory as a special case, in a way 
which is natural and sheds some light on that case. We belicve that our model has contributed much to the 
classical theory. For example, the 1/O automaton modcl provides a gencral underlying model, a missing 
component of the classical theory. Also, our explicit and gencral modclling of the transactions unifics the 
carlicr collection of somewhat arbitrary approaches. Our use of the transaction interface for stating 


correctness conditions is also an improvement. 


Another contribution to the classical theory is in motivating scrializability as a correctness condition. 
Scrializability consists of two criteria: individually, cach transaction must sce a consistent state, and together, 
they must appear to run in a serial order. (A schedule in which each transaction reads and writes the initial 
state of the database provides a consistent state to each transaction, but is not serializable.) Why is this second 
ordering property a part of the gencrally accepted correctness condition of the classical theory? Clearly, 
because of implicit nesting in the context of the transaction system. In practice, transactions perform tasks on 
behalf of some external entity or cntitics, which may expect onc transaction to see the results of the next. In 
the natural formulation of classical systems within the present modcl, the classical transactions are children of 
To 
environment in which the system runs. Thus, the ordering property of serializability is a natural consequence 


with data accesses as their only children. ‘The root is an explicit representation of the external 


of the requirement that all transactions sce serial schedules, including To: It docs not have to be introduced as 


an independent requirement in need of separate justification. 


By now, there has been a large amount of systems design and algorithms work that uses or impicments 
nested transactions. It seems likely that these idcas will form the basis of future programming languages for 
distributed computing. However, there is currently a problem with the presentation of this work. Some of 
these algorithms are presented in the context of specific systems and programming languages. Very uscful 


and general ideas are too intimately connected with details of the systems to be fully appreciated, particularly 
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for readers with only a passing understanding of those systems. ‘This level of detail also makes careful 


reasoning about the algorithms very difficult. 


We believe that our mode! has provided the necessary framework and some of the necessary vocabulary, for 
describing this work in a clear and unambiguous way. We are currently studying much of this work on 


systems design and algorithms using our model, and our preliminary results indicate that it works very well. 


‘Throughout the paper, we have described connections with other people’s work as appropriate. Here, we 
mention some of the particular modelling work that relates most closcly to ours, and describe the connections 


in more detail. 


First, the pioneering work of Bernstein and Goodman [BG, etc.] has had a strong influence on this work. 
Quite carly, they recognized the need for a model for single-level transaction systems, that would have many 
of the characteristics which we have sought for nested transaction systems. ‘They have carried out extensive 
research on precise understanding of single-level transaction concurrency control algorithms. They have 
presented formal statements of correctness conditions, in terms of scrializability of the accesses to data objects 
by different transactions. They have described some concurrency control algorithms with precision, and have 
proved correctness of some algorithms, using a lemma which characterizes scrializability by absence of cycles 
in acertain dependency relation. ‘Their work has gone a long way toward providing precise understanding of 


the work in this area. 


However, the particular models used by Bernstcin and Goodman have some problems which limit their 
applicability. For instance, the basic correctness condition is stated in terms of the interface between the data 
objects and the algorithm. ‘There are many algorithms which handle objects in very different ways, e.g. using 
multiple versions, or making multiple copies in order to permit “backing out” of operations. Since these 
algorithms do not preserve the specified object interface, they would not be considered correct under the 
same correctness condition. Thus, the correctness condition must be modified. Another limitation is that the 
proof technique, which involves proving absence of cycles, is a proof by contradiction; it does not give much 
insight into the operation of the algorithms. For many reasons, it is not at all clear how to extend these 


frameworks to handle nesting of transactions. 


Earlier attempts in [Ly,Go,BBGLS] to model nested transactions have made significant contributions. For 
example, [Ly] contains a language-independent model, which is uscd to give precise correctness conditions 
and a proof for a locking algorithm. Many of the ideas in that work have been uscful in providing a 
vocabulary for talking about nested transactions. However, attempts to extend the model of [Ly] to handle 


correctness of orphans [Go] demonstrate that it is not sufficiently expressive. Certain aspects of the model 
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lead to technical difficultics; for cxample, it fails to model the transactions explicitly, using instcad a 
specification of their behavior, Our new model builds on the strengths of the carlier work, while managing 


(we believe) to avoid its weaknesses. 


Finally, the very recent work in [BBG] proposes another general model for nested transactions. While on 
the surface the modcls appear quite different, they are actually "compatible", in that the concepts described in 
[BBG] seem to be easily definable within our model. ‘he style of the model in [BBG] is different from ours: 
their work models transactions and the scheduler implicitly, for instance. However, we belicve that their 
important axiomatic statements of properties can be described as assumptions and lemmas about behaviors of 
components in our modcl. Also, the partial ordcrs which they use to model executions can actually be 
defined simply and dircctly in terms of our lincarly-ordcred executions. ‘There are many points of agreement: 
the use of the transaction interface for stating correctness conditions, and the use of the virtual root 


transaction To to mention two. 


On the other hand, the emphasis in [BBG] is on a different example than the onc studied in this paper. 
They consider multiple levels of abstraction for the data, and regard transactions at any Ievel of the 
transaction tree as accesses to data at a corresponding level of abstraction. ‘This vicw meshes quite well with 
our model, where, for example, we use the same CREATE notation for creation of a transaction and 
invocation of an opcration on data. Their paper clarifies the concurrency control requirements for data at 
different Ievels, when the correctness condition is serial correctness at Tp We hope and expect that it will be 


easy to restate their results as claims about our model. 


We note that the work in [BBG] only treats concurrency control, but does not address the very critical and 


difficult issucs of resilicncy. 


9. Further Work 

This paper is an embarkation on a major project to formulate a unified presentation of the most important 
algorithms for concurrency control and resilicncy, especially those for nested transactions. So far, we have 
defined a general framework mecting the requirements outlincd above. We have demonstrated the power of 
this framework by using it to specify two correctness conditions for nested transactions, to present two locking 
algorithms for implementing nested transactions, and to prove that the algorithms satisfy their respective 


requirements. 


Future extensions to this work will include treatment of many other algorithms in the same framework. 
Among the algorithms we will consider are timestamp and multiversion algorithms, algorithms which take 


advantage of special properties of the transactions and objects (semantic information), algorithms for orphan 
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management, and algorithms which use replicated data objects. Although our focus so far has been on nested 
transactions, we believe that our viewpoint contributes new insight to the special case of single-level 
transactions as well: thus, we will examine algorithms for non-nested transactions as well as nested 


transactions. 


We arc particularly interested in studying algorithms which give rise to live orphans, i.c. live transactions 
whose ancestors have aborted [Go,1.i,Wa,HM]. Our scrial correctness condition provides a formal definition 
of orphan correctness ~ that all transactions (including orphans) "sce consistent data" [Go]. In fact, in work 
currently in progress [HIM W], we are describing and proving correctness of several of the recently-developed 
algorithms for orphan management. ‘This work now sccms to be quite casy, given the foundation provided by 


the present paper. In fact, some of the key results of this paper arc used as lemmas in that work. 


Another direction of interest is the explicit representation of distribution within the model. It is fairly 
natural to model cach transaction and object as located at different sites, cach with a local automaton 
representing the resident portion of the (distributed) scheduler. ‘These automata would communicate with 
cach other in order to implement the (centralized) scheduler studicd here. ‘Vhe natural next step would be to 


model failure resilience, as various components lose information or fail altogether. 


The reader might have noted that our correctness conditions do not guarantec anything about the system 
making progress, but only about “safety” properties. Further work is needed to incorporate guarantccs of 
progress. ‘This work is likely to be difficult, however. Only recently, in [LT], have we achieved what we 
consider to be a satisfactory understanding of the eventuality and fairness issucs for the basic [/O automaton 
modcl, so that we can even formulate the conditions we want to satisfy. But even with the ability to state such 


conditions, the algorithmic issues still seem difficult. 
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